Query about Global Exception Handler and library activities

[SoqedHozi]

Hi all,

I have a query about the logic of global exception handlers.

In my workflow I use library activities, such as “download report”. My workflow calls this repeatedly until it returns a FileNotFound exception (I use a try/catch for this).

On occasion the download activity will fail for a different reason and it needs to be handled, so I have a global exception handler that currently asks it to retry and then aborts if it still fails after 3 retries.

I’d like to try an application restart before aborting, but I need to understand how the handler works more first.

The way I see there’s two potential flows, either:
A) the library activity fails on activity X, this returns a failure that triggers the GEH. This then retries activity X.
B) the library activity fails on activity X, this returns a failure that triggers the GEH. This then retries the library activity from the start.

Any guidance on how this works would be appreciated, thanks.

[Jeroen_van_Loon]

The basics of error handling are as follows:
At any point, where an exception is thrown, it is handdled by the inner most exception handler, seen from the point of view from the entire autamation.

In the catch component the error is handled, and resolved. The script will continue towards the finally part and then continue outside the error handler. If a new error occurs (throw or rethrow) it will then proceed to the inner most exception handler from that point on, etc etc.

The global error handler would be your outer most error handler in your process. Any errors that occur outside of this global handler will fail the entire automation.

This mechanism is consistent for library activities, workflow files or just nested activities.

Which functionality is retried where would then depend on your own design choices… what action do you want to undertake when…

If you want to differentiate in types of error, you can process that in your exception handler, or even make more than one exception type handlers in the same try / catch.

You could do this (freehand example):
Library activity x fails → error is thrown
GEH:
if exception.message.contains “file not found” => dont retry
if exception.message.contains “some ui error” => close applications, restart applications, retry item
if exception.message.contains “any other error” => retry item

So 1 handler, that handles different scenarios based on the error type, which gives you the flexibility to follow up appropriately.

[SoqedHozi]

So because the GEH sits outside of the try/catch that calls the library activity, the erroraction.retry would retry the try/catch AKA retry the library activity from the start AKA scenario B.

This is what I expected, but I wasn’t sure if the specific sub-activity shall we say would be known to the project.

This mans I can use restart then, as it will follow all the library activities steps, and not retry a type into (say) halfway through to a field on a page that might not be loaded without running prior steps.

I also like your suggestion of using exception.message.contains to make the GEH more precise.

Thanks