Exception Handling and Error Management
The exception model
Blue Prism distinguishes System Exceptions (raised by the platform, e.g. an application not responding or an element not found) from Business Exceptions (raised deliberately when data or business rules are violated, e.g. a policy number that does not exist). The distinction drives recovery: system exceptions are usually retried or escalated to a human; business exceptions normally mean the item cannot be processed and should be marked accordingly.
Mechanism: an Exception stage throws; a Recover stage catches everything thrown in its enclosing Block, page, or process scope and routes to a recovery path; a Resume stage returns control to the stage after the one that failed. Use Blocks to scope where recovery happens, and keep recovery paths short and explicit.
Traps in questions
- Assuming Recover catches only one type - it catches whatever is thrown in its scope, so scope design matters.
- Confusing Resume (continue after the failed stage) with retry (loop back and attempt again).
- Throwing a system exception for a business rule violation, which pushes a data problem into technical retry logic.
- Leaving an exception path that does not end the process or mark the queue item, causing silent data loss.
- Catching an exception and continuing as if the step succeeded.
Rule of thumb
Ask "whose problem is this?" - if the data is wrong, it is a business exception; if the environment failed, it is a system exception. Recover close to the failure, and always leave the item in a known state.
Worked example
A login times out. That is a system exception: Recover, retry a bounded number of times, then mark the item as an exception for review. An account number that fails validation is a business exception: mark the item as an exception immediately without retrying, because retrying cannot fix bad data.