Error types

The errors that you may encounter when running your flow fall into different categories:

Permanent errors

Let's say you are using the Webhook building block and have entered a URL that does not exist. Ultradox will try to call that URL and every single time the block gets executed it will fail with the same error.

You could also have create a JavaScript block with some illegal code in it. The execution of the script will fail each time you run the block, until you fix the code.

Permanent errors are bad, but they are luckily easy to fix. Just fix the configuration or the code of your script and they will go away.

Temporary errors

Temporary errors can occur if a service that you are using is currently not available. These errors are harder to fix as they cannot easily be reproduced once the service is back.

Error message

Errors can be distinguished by the error message. It contains information about the cause of the error and may look like this:

Failed to process template, incomplete tag=Hallo ${nam

This message indicates a permanent error in your template that should be easy to fix.

An error message could also look like this:

Received exception executing http method GET against URL https://www.theservice.com: Connection timed out: connect

It seems to be a temporary error as the service is not responding and caused a timeout.

Error handling rules

Each building block can be configured with a set of error handling rules. If no rules are specified, Ultradox will immediately throw any error.

 To configure the error handling rules, click on the error icon that you find on the right of the building block toolbar.

You can define multiple rules matching different error messages and specify how Ultradox should deal with the matching errors.

Let's say you have created an app that will log the current user and time into a Google Sheet whenever the app gets launched.

If the Google Sheets service is currently not available and throws an error you may just want to ignore this error and continue with your flow.

In this case you can define a rule that any error on this building block should be ignored:

If error matches	Retries	Then
.*	0	Ignore error

What does this configuration mean?

The first column contains a regular expression describing the matching error messages. In this example it will match any error message.

The second column specified the number of retries that should be performed if a matching error is detected. It is set to 0 so no retries will be performed.

The third column specifies if the error should be thrown or ignored if the maximum number of retries has been reached. As we have set the number of retries to zero, the error will be ignored immediately and no retries will be performed.

Automatic retries

Now let's improve the error handling by configuring the number of retries. Retries only make sense if you encounter a temporary error, like a connection timeout.

So we will add a number of retries only for error messages, that match the first rule.

If error matches	Retries	Then
.*timed out.*	3	Throw error
.*	0	Ignore error

The rule starts with .* matching any character, is then followed by timed out and finally by .* which again matches any character. The complete rule will match any error message that contains the text timed out.

All other errors will match the next rule.

This configuration will lead to the following behaviour:

If a timeout occurs, Ultradox will automatically retry the same action up to 3 times. The delay between the retries will be larger on each try to give the service a good chance to revive.

If the third retry also fails, Ultradox will throw the error and abort the flow if the error is not catched somewhere else.

Any other error on this building block will simply be ignored.

Try / Catch blocks

Now that you know how to configure error handling rules on a building block we can take our error handling knowledge to the next level.

Using the try and catch blocks you can perform a number of steps if you have encountered a certain error.

You may for example want to send an email to the developer of a service if the service is not responding even after retrying multiple times.

When dragging a Try block into the flow it will automatically also add a Catch block and a matching End block.

You can then put a number of building blocks after the try but before the Catch block.

If any of these building blocks throws an error you can catch it and perform a number of steps you put right after the Catch block:

Try to execute the following blocks

Execute webhook Load customers

Execute webhook Load usage data

Catch errors

Send email with subject Error at  ${now;datetime(op=short)} to [email protected]

End of error-prone blocks

No matter on which of the nested block the error occurs, the execution will then continue right after the Catch block.

Using this approach you could also wrap your complete flow into a Try / Catch block and log the errors in a Google Sheet.

You can nest Try / Catch blocks to do a more fine grained error handling.

Throw errors

Sometimes it makes sense to throw your own error. If you have created an automation that gets called from your own application and the passed data cannot be processed, you may want to stop the execution by throwing an error.

This makes also a lot of sense if you are creating subflows that can be called from different apps or automations.

Your own errors can be handled and catched in the same way as system errors.

Questions and Feedback

If you have any comments on this page, feel free to add suggestions right to the Google document that we are using to create this site.

If you are not yet member of the Ultradox community on Google+, please join now to get updates from our end or to provide feedback, bug reports or discuss with other users.

Last Updated: 10/17/18