My bots occasionally get stuck on a pop-up window or a loading screen and just sit there for hours until I manually kill the process. How do I program a "Global Exception Handler" that can take a screenshot, close the application, and restart the process automatically?
3 answers
The key is using a "Try-Catch-Finally" structure at the highest level of your workflow. In the "Catch" block, you should invoke a "Kill Process" activity to clear the environment. For professional-grade bots, you should always include a "Get Screenshot" activity in the catch block and save it to a shared drive; this is vital for debugging "unseen" errors on a virtual machine. In the "Finally" block, ensure the bot logs out of the application so the next run starts with a clean slate. Also, use "Timeouts" on all UI activities—never leave a 'Wait' to 'Infinite'. If a screen doesn't load in 30 seconds, throw an exception and move to the next item in the queue.
Do you distinguish between "Business Exceptions" and "Application Exceptions"? Handling a missing data field is very different from handling a website crash.
Use a "State Machine" layout for your main bot logic. It makes it much easier to define "Success," "Failure," and "Retry" states compared to a standard flowchart.
I agree with Mary. State machines provide a much clearer visualization of the bot's recovery paths, making long-term maintenance significantly easier for the support team.
William, I haven't been doing that, but I see why it's necessary. Right now, a technical crash and a missing zip code both trigger the same retry logic, which is a waste of time. How do you structure the bot to "retry" a system crash but "skip" a business error where the data is simply wrong? Should I be using different "Catch" blocks for specific exception types like 'System.Exception' versus a custom 'BusinessRuleException'?