Goal number one for any automation being built is obviously to complete the task at hand - be it reconciling data between applications, sending off emails, doing web scraping, and/or some combination of all of the above. That’s why we’re using RPA in the first place right?
If your goals stop there though, you may be putting your automation process, bot runner, and possibly other scheduled processes at risk. A clearly defined, and crucially important, goal number two must also be considered: keeping the bot from hard failing.
Fortunately approaching this stability focused goal is easy to implement in Enterprise A2019 and should be fearlessly approached by both new and experienced bot builders. In this article, we’ll break down the actions of the Error Handling package to understand the appropriate use for each so your bots can safely exit (and log) should an error occur.
Why Error Handling Matters
You may have heard of a phrase “happy path” in business process breakdowns or development discussions. Happy path refers to the steps taken to successfully complete a process when everything is working as expected: the data is correct, its properly formatted…the applications used all have the fields we expect, they are responsive, load quickly, and allow for a user (or bot) to complete submission.
Clearly the happy path should be the focus of a bot build, but what happens when the data we get isn’t in the format expected? or input data is missing? What happens when the website we’re trying to enter data into isn't loading as quickly as it used to? or fields that we were previously using for data entry have gone missing?
Enter considerations for the “unhappy path”. Error handling built into a bot allows the bot to appropriately respond when something isn’t working as expected. When data is formatted incorrectly - we don't want the bot propagating that data to other systems - so we add data validation checks to prevent that from happening. When applications don’t respond the way we expect, or a file that should be available suddenly isn't - we need to make sure we have appropriate ways for the bot to handle the unexpected circumstance. The solution then, is to try to programmatically handle things we can check for (data validation checks) and use error handling to address everything else. This is where the Error Handler package in Enterprise A2019 comes in.
The Error Handler package is made up of 4 total actions. Let’s take a look at each to fully understand how and where they should be used within a bot so that you can confidently approach adding error handling to your own future bot builds.
Error Handling Package: Try
When we think of “happy path” - it’s the case where all data, applications, and dependencies are working as expected. All of the happy path related code belongs inside of the “try” block created by the Try action. Try establishes a block where all code can be added. If any exception occurs during that processing, the bot will “throw” an error - which could call the Catch block (if a Catch block has been added) or call whatever comes AFTER the Try block (if no Catch block has been added).
If things run smoothly, then everything inside the try block will be executed - and whatever comes AFTER the Try block could execute. The Catch block wouldn’t be called in this case as no error has occurred.
Looking at an example: This basic bot has 2 actions inside of a Try block:
- Copy a file from one location to another
- Open the file after the copy has occurred
What if the file for copying doesn't exist? What if the open command is actually the wrong path and the file was copied elsewhere? In either case, the try block would execute - should either action inside the try block fail, the bot would run the Message Box action. Think of try as “making an attempt” to run the actions within. Should that attempt fail, it automatically skips to run whatever is next - in the case of our example, a Message Box that says Done.
The behavior described is perfectly valid to use in certain situations, but more commonly something should be used to handle the exception. Enter the Catch action.
Error Handling Package: Catch
The Catch action is used to handle any exception that may occur in the Try block. Instead of going below the try block like most commands, it actually goes to the side of the try block (if viewing in flow view). The configuration for the Catch action is pretty straight forward.
- Provide a variable to hold the exception message - which is to say if my bot errored off on the Open File action for example, what message did the Open File action return with for its reason for the error? This should be stored in a variable that you reference when logging the error so you can have some insight into what may have gone wrong.
- Provide a number variable for the line number - which holds the exact line number that errored off, and like the error message, should be stored in a log file for troubleshooting and further investigation. While the line number doesn’t make a ton of sense in flow view, upon switching to list or dual view, you’ll see that each used action has a unique line number and can be individually referenced. Again - very helpful for getting insights into issues that occurred.
Now, the goal for the Catch block should be “Do whatever is needed to document/log the details around the error”. Remember - because the error has been “caught”, the bot didn’t just hard fail, so that's good news, but we still want to make sure we understand exactly what happened so we can correct for it in the future. This likely means doing some logging to capture the error line and description as well as potentially capturing a screenshot of the machine state at the time of error. This screenshot is especially useful for unattended bot runs - so you can see if applications weren’t opening properly, or fields weren't showing up as expected.
The most important point to remember about the Catch action: The code inside of the Catch block ONLY executes if there is an error. If everything in the try block runs successfully the Catch block would NOT execute. Keep that in mind as you determine what code is/isn’t appropriate for the Catch block.
Error Handling Package: Finally
Like the Catch block, the Finally action creates a block to the right of the Catch block in flow view - creating a 3rd block/swim lane for code. Unlike the Catch block, however, the code in the Finally block executes regardless of the success or failure of the Try block.
That last part is very important, so to hammer that point, let’s look at an example task:
The solution from the Try discussion has been built out to include both a Catch and Finally block. In discussion of the try block, we posed “what if the file we tried to open didn't exist?”. Based on the bot pictured, the Catch block would execute which would log the error to file and capture a screenshot of the desktop saved off to a network share. Afterwards, the finally block would execute indicating that processing was complete (though not completed successfully as we know).
The flip side of this - let’s assume the actions in the try block all execute successfully. In this case, the Catch block would not execute, though the finally block would still run indicating that the processing was complete.
Given that the Finally block executes either way? Why use it? “Do I really need a message box to pop up at the end of my process regardless of success?” The answer is that the finally block is VERY useful for a couple things.
- Use it to close applications which your bot may have opened. In the example pictured, the bot is doing some file operations before it opens excel. If it had a failure in one of the Excel steps, the bot may inadvertently leave Excel open which could cause file locking issues or some confusion for the next bot to be run on this bot runner. You could also consider using those close commands inside of a Try block inside of the Finally block. (Did that just blow your mind?!?) This way the bot will try to execute the Excel close command - if it fails (because Excel wasn't actually open) the bot just continues processing. If it succeeds, great - the bot still just continues processing.
- Use it for logging. When I build bots, I’m typically thinking of the different functionality of a bot as modular pieces which must be accomplished to contribute to a greater automation. To that end, I’m also trying to log when each of those modular pieces starts and ends - so that as I’m looking back through an audit log, I can kind of put together exactly how processing went and what happened. The finally block is a great way to implement such an approach.
Error Handling Package: Throw
The final action of the Error Handler package is the throw action. Throw allows you to self-trigger an error through use of the action. Why would you ever want to do that? Think of a scenario where your bot is reading data from a spreadsheet that should have a valid employee ID for each employee in column A. Upon looping through each row, an if statement is added to check the contents of column A for each row to validate that it does indeed have an employee ID. Come across a row that is NOT a valid employee ID or is blank? Rather than propagating that bad data into other business systems through the bot, use the throw command to trigger the Catch block which can record the error. The Try-Catch-Finally blocks can be used inside of loops, so throwing such an error wouldn't necessarily have to stop processing for the entire automation, just stop the processing of that one data record and log it.
Conclusion
Error handling can be intimidating at first because it looks like it adds a lot of confusion to your code - but the reality is that it doesn't have to be. Play around with small sample bots like the one pictured in this article to help build confidence in your understanding of when each block executes…before you know it, you’ll be confident enough to include responsive error handling in all of your bot builds. Happy building!