Exception Handling in blue prism
Exception handling is defined by the management of exceptions in unassisted automation. It ensures that problems can be automatically resolved if possible, or easily identifiable and repairable by system administrators or passed for human completion where appropriate. If left unhandled, exceptions could drastically impair RPA functionality. The success of exception handling depends on how well it is implemented during development.
Exception handling is a critical part of any Blue Prism solution and should be designed with the same level of care afforded to the other parts of a solution. Focusing only on the ‘happy path’ is not sufficient – the ‘unhappy path’ must also be considered.
Although not every type of exception is recoverable, and sometimes it makes no sense to attempt a recovery, the ability to handle exceptions at least provides us with the opportunity to decide what to do when processing does not perform as expected and the logical flow has strayed from the ideal path.
Most exception handling should be done at process (or component) level. Business objects can contain exception handling but in general they should be kept as simple, reusable pieces of logic. In the following exercises we will look at a scenario where exception handling is commonly used at business object level – when we launch or attach to an application.
Handling an Exception
In its current state the business object generates an exception when it tries to attach to a non- existent Notepad. Remember that if left unchecked, an exception will bubble upwards towards the main page of the parent process, ultimately bringing the process to a stop.
In this next exercise we’ll handle the exception to prevent this from happening. And because we know (or at least can reasonably assume) that the exception can be interpreted as ‘Notepad is not launched’, we can add additional logic to remedy the situation.
- Add Recover and Resume stages to handle the exception, with your diagram looking like this (NB the note stage isn’t necessary).
- Run the page again to confirm the exception handling prevents the message from appearing. This puts the object back on the ‘happy path’ but does not do anything to improve the situation
- Add another Navigate to launch Notepad after the Resume stage, like this
- Run the page and confirm that Notepad is launched.
- Press the Detach button and run the page again. Now because Notepad is already launched the attach will work.
Run the page again (slowly) to see that although the exception handling works at first, the diagram falls into a loop when it tries to launch Notepad. What do you think is happening?
- The attach failed initially because the business object was already attached, and a business object cannot attach more than once.
- This exception was handled but then the launch failed because Notepad was already running, and once attached, a business object cannot launch again
Isolating Exception Handling
- Although very useful, exception handling can itself cause problems if not well laid out.
- By default a Recover stage will attract any exception occurring on its page, and this can sometimes lead to an infinite loop.
- A Block is a mechanism for isolating exception handling to a specific area and is a good way to prevent an infinite loop.
Avoiding an Exception
- Sometimes we can make checks to avoid scenarios where an exception might occur