API Testing and Monitoring with Error Handlers

Let's suppose that there's a part of your automation that encounters a problem. Without error handlers, this small error can escalate to a major problem and slow down everything, including your work. But by using error handlers, you could avoid the issues from aggravating the situation. Error handlers maintain robust and reliable automated systems and are responsible for ensuring that even if things do not go as expected, the systems can be relied on.  

Error-handling in Make: A practical scenario  

This specific scenario was created in Make to help demonstrate the role of error handlers. In this case, a module from 0CodeKit has been assigned the role of identifying the gender of a particular person depending on the name. The purpose is to demonstrate the ability of error handlers to deal with cases when the module is faced with an unknown piece of data or is unable to find the required information.

Now, it might be the case that the name in question is not recognized, or perhaps it is not a name but a word that has no business being in that field, which makes the module fail. The problem with errors is that they slow the automation flow down, and everything that comes from a broken module does not trigger. To avoid this, we use error handlers.

Make provides a wide range of native error handlers, but one can also specify his/her error execution plan as well. To create an ‘error handling path’ from a module, which is the path that the automation is going to follow if the module fails, you right-click on the module and then click on "Add Error Handler".

From a visual perspective, it looks like yet another process in the workflow. The thing to note is that it will only execute when the module detects an error. In our example, we could use the error handler to write an email using genderless words. So, if the module is unable to identify the gender from a name, the email would still go through, although more neutral or generalized.

For this purpose, a simple alternative would be the "Resume" error handler. This error handler enables one to provide default values to the fields that the failed module should have filled. In our case, we can make the gender field optional, which means that in cases where gender is not stated, it will be assumed that it is “unisex”. In this way, each time the module did not identify a gender's name, the automation would automatically proceed towards the ‘unisex’ branch without an error message that would stop the scenario.

Other error-handling options  

Error handlers can be seen as automated processes, ensuring all errors will be handled properly. It provides a way of managing business when things turn sour. Suppose you are running a scenario, and something unpredictable occurs. Rather than everything coming to a stop, error handlers can react in a certain way to these events. These are other error handler options:  

• Ignore: This one just overlooks the errors and allows the scenario to continue. That is good when minor errors cannot impact the plan or scheme of things.  

• Resume: If there is a mistake, "Resume" is always ready with contingency measures. It can use a substitute, so that the scenario can proceed without a hitch.  

• Commit: This one pauses the current operation and writes the changes to the database it is working with. However, it only does this if the scenario contains specified sorts of database operations.  

• Rollback: It's like an undo button as Rollback reverses actions. However, it can reverse only specific types of actions, not the whole workflow.  

• Break: It erases all the negative elements of the scenario. It logs what went wrong so that you can revisit the content later and rectify the error. Depending on the settings, Make might complete these scenarios or temporarily leave them for later correction.