Beau

Alright, Jo. So we've figured out how to build these workflows, pass data around with arguments, and even wrestle with those tricky selectors we talked about. Our bot works… you know, on a good day. When the sun is shining and the website we're scraping hasn't changed a single pixel.

Jo

The 'happy path,' as they say. And building for the happy path is easy. But what really separates a hobbyist bot from a professional, enterprise-grade bot is how it behaves on a bad day. When the network drops, or the invoice it's trying to read is… well, formatted by a toddler.

Beau

Okay, so we're talking about making them less fragile. So they don't just fall over and die silently at the first sign of trouble. Where do we even start with that?

Jo

We start with the foundation of all error handling in UiPath: the Try-Catch-Finally block. It's an activity you literally drag into your workflow.

Beau

Try-Catch-Finally. That sounds familiar from, like, general programming concepts, right?

Jo

Exactly. The concept is identical. The 'Try' block is where you put your main sequence of activities—the happy path. This is what the bot will *try* to do. So, let's say, open a browser, log in, download a report.

Beau

Okay, that makes sense. So what happens when something inevitably goes wrong in that block?

Jo

That's when the 'Catch' block takes over. The bot immediately stops executing the 'Try' block and jumps to the 'Catch' block. This is where you define what to do when an error, or 'exception', happens. You can log the error, send an email to an admin, maybe try an alternative method...

Beau

So instead of just crashing, it has a Plan B. And what's the 'Finally' part for?

Jo

The 'Finally' block runs no matter what. It executes if the 'Try' block succeeds, and it executes if the 'Catch' block is triggered. It's for cleanup. Things like closing the browser window or logging out of an application, whether the process worked or not. You don't want to leave a dozen browsers open just because the bot hit an error.

Beau

Got it. So, 'Try' is the plan, 'Catch' is the backup plan, and 'Finally' is the cleanup crew. But you said 'exception'... are all errors the same?

Jo

No, and that's a crucial distinction. In RPA, we generally categorize them into two buckets: System Exceptions and Business Rule Exceptions.

Beau

Okay, break that down for me.

Jo

A System Exception is when an application or the environment fails. The website is down. The network connection is lost. The login credentials you were given are wrong. The selector we built can't find the button because the app updated. It's an IT problem, something the bot usually can't fix on its own.

Beau

So, that's like an external failure. What's a Business Rule Exception then?

Jo

A Business Rule Exception is when the data itself doesn't meet the process requirements. For example, the business rule says all invoices must be over ten dollars. The bot gets an invoice for five dollars. The bot didn't fail, the application didn't crash... the *data* failed the business rule. It's a logical error, not a technical one.

Beau

And you'd handle them differently, I assume. For a System Exception, you might... I don't know, retry? For a Business Exception, you'd just mark the invoice as invalid and move on.

Jo

Exactly. You've hit on a key tool for system exceptions: the Retry Scope. It's another activity in UiPath. You wrap it around an action that might be a bit... flaky. Like clicking a button on a slow-loading webpage.

Beau

So it's like a mini Try-Catch that just... tries again? How does it work?

Jo

You can configure it to retry a certain number of times, with a specific delay between each attempt. So, instead of the bot failing immediately because the 'Submit' button wasn't there yet, you tell it, 'Hey, try to click this three times, and wait two seconds between each try.' Most of the time, that solves temporary UI loading issues.

Beau

That's brilliant. It's like building a little bit of patience directly into the bot. So we've got Try-Catch for overall structure, Retry Scope for specific wobbly steps. What if something goes completely off the rails? An error we never even predicted.

Jo

That's where the Global Exception Handler comes in. Think of it as the ultimate safety net for your entire project. It's a separate, special type of workflow that you designate in your project settings.

Beau

So if an error happens that isn't caught by any of my Try-Catch blocks... it goes there?

Jo

Precisely. It catches any unhandled exception in the entire automation. Inside this global handler, you can decide what to do. You can log the final, fatal error, maybe send a high-priority alert, and then choose to either gracefully abort the process, ignore it, or even retry the whole thing from the beginning.

Beau

So you have local error handling with Try-Catch, and then this... well, global one as a final backstop. It feels like layers of security.

Jo

That's the exact goal. And a huge part of all this is logging. It's not enough to just catch an error; you need to record what happened, where, and why. UiPath has a 'Log Message' activity. You should be using it everywhere.

Beau

What do you mean? Like, what kind of stuff do you log?

Jo

At the start of a workflow, you log that it started. When you process a transaction, you log the transaction ID. When an error occurs in a Catch block, you log the exception message and its source. You can set different logging levels, from 'Trace' for super detailed step-by-step info, up to 'Error' or 'Fatal' for critical failures.

Beau

So when the bot fails at 3 AM and you come in the next morning, you don't have to guess what happened. You have a detailed diary of its last moments.

Jo

A bot's diary, I like that. Yes. And it's essential for debugging and for auditing. Now, one last piece to this puzzle: the 'Throw' and 'Rethrow' activities.

Beau

Throw? Like... you're creating your own error on purpose?

Jo

Exactly. This is how you create those Business Rule Exceptions we talked about. If you check an invoice amount and it's less than ten dollars, you use the 'Throw' activity to generate a new Business Rule Exception with a message like, 'Invoice amount is below minimum threshold.' This stops the normal flow and triggers a Catch block.

Beau

Okay, that's clever. You're using the error handling system to manage your business logic. So what's 'Rethrow'?

Jo

Rethrow is used inside a Catch block. Imagine a small workflow catches an error. Maybe it logs some local details about it, but it can't fully resolve the problem. It needs a higher-level process to handle it. So, after logging, it uses 'Rethrow' to send the exact same exception up the chain to the workflow that invoked it.

Beau

Ah, so you're not swallowing the error. You're dealing with part of it, then passing the baton. It sounds like this is all about making sure no bot ever fails silently. You're always in control of what happens when things go wrong.

Jo

That's the absolute core of it. A bot that works 99% of the time but fails silently that other 1% is a liability. A bot that works 99% of the time and, on the 1% it fails, it logs the error, notifies the right people, and cleans up after itself... that's a professional bot.