Chapter Seven exception handling. In this chapter, we'll be giving an overview of four exception handling is. We'll talk about Exception Handling stages, exception bubbling, and exception blocks. Overview no matter how good we try, there would be cases when an abnormal situation arises and disrupts the normal execution flow of a program. This inevitable behavior is not limited to RP bots, but is a pretty common occurrence across our daily jobs when performed manually. It can be related to instances such as not being able to log into a website do internet connectivity issues or login credentials not working due to recent system upgrade, unable to start an application due to some system files which got deleted during recent system cleanup etc, etc.

If set situations are not properly handled, they may lead to a chain of problems affecting the other system. Seated actions, causing a complete failure of operations. The bar should be made capable enough to be able to debug such issues and take appropriate action. This is also called recovery mechanism for the process, which plays a crucial role in making the bar robust and reliable. represented has several stages and underlying concepts that developers can make use of to handle errors or exceptions effectively. As mentioned before, that there should be a legible naming convention we must use to depict the operations performed by each stage within the bot.

Its relevance is realized during this error management process. Exception Handling stages to understand the concept of exception handling in blue prism, we have to take analogy from the software programming languages. When an exception is encountered by a program, it must be caught. once caught appropriately, we provide These statements to handle it based on the recovery mechanism to be implemented. An example would be to try out launching an application a few more times, if it didn't open up in the first attempt itself, before making it as an error. This is how we perform operations manually as well.

I'm sure we don't give up on a task simply because it didn't go as expected since the beginning itself. Once the recovery mechanism is executed, we resumed the operation so that it comes out of the recovery mode and continue execution. Let's define the stages in detail within the blue prism program itself. So first we're going to talk about is recover stage. This stage is used to catch an exception that occurred in a program. Once the program execution is directed here.

It gets into a recovery mode, where the stages corresponding to handling the exception are given Like subsequent to the record stage, then we also have a resume stage. And this stage resumes the process flow by getting it out of the recovery mode and let the bar operate in normal mode. This stage marks internally that the exception has been taken care of, and normal execution shall be executed or shall be proceeded. All exception related data like name detail etc gets diffused. Once the program's executes this resume stage under normal execution, if same exception occurs again it will be caught by the corresponding recover stage. Right.

And we also have something called an exception stage. So far, we have only dealt with the exceptions that are generated internally within the box stages. However, it's possible for the program to throw an exception explicitly and this process of users Define exception redirection is called throwing an exception. And it is accomplished by using this particular exception stage and the blue prism. This stage lists the type of exception that a stage might throw along with the associated details. So let's use these three stages to increase the reliability of a bot.

We have used the action stages before where we were accessing the business objects to launch a CRM application, right, which is right here in the on the desktop. And suppose due to any unknown reasons, our application didn't run in the first attempt, right? Either the file is not available there at all, or the file name has changed and could be plenty of other reasons. Right. So to try launching the app again, we keep a track on the number of times the launch action has been attempted. And if the number of retries goes more than three or any any threshold limit that we may set, we abort the whole process.

Right? It's a pretty sophisticated Exception Handling mechanism, which is also generally followed by system users. Right? Once you're working. And if you're not able to open this application, you won't just you know, about the whole process, you would probably give it a few more retries. before deciding on the fact that, you know, the, there's some sort of error and that you cannot execute the file at all.

Right? So this retry thing is what you want your bot to be capable with. So the overall process is going to be something like this, we're going to create it right away. First, we'll have the action stage where we are going to access the business object corresponding to the launching of the CRM application. So we have the Bo, we already created this one, and we're going to access the launch page. Right so we go to the action And this is gonna be new Bo and launch page.

Okay. And you're gonna compute any further stages, you know, there could be other actions also involved. But to showcase these three stages, I'm just gonna put a note here saying further stages, whatever. Okay. And if there's any problem with any of these, there could be like more, of course, stages here. But if there's any problem, then this, the program would get redirected to the recover stage.

We're going to show that in a minute. And let's say we're going to put that recovery mechanism now. Once it goes to three Copper stage, the program's in recovery mode. Now it's not in the normal mode, like the way the process flow execution works. So it's in the recover mode, and we create a decision. And this decision is gonna decide whether we want to retry launching the application or not.

Right? And do that we keep a track of, okay? It's a initial value of zero. We have to retry. And if retry is less than three, right? If this is true, then we want to launch the application again, right.

So What we're gonna do is first we are going to increment the retry variable so that you know it keeps a track. So you take the calculation stage, okay. So that means this condition is true then increment the array and we simply resume and that's good change this applications. Change is not the correct word property. Let's use stages to make this look better. That's what it meant the array, right?

It's gonna resume which means it's gonna be getting out of the recovery mode. It's gonna get back to the normal mode. And now it's going to launch the application. Again, if it works, then the further stages would be executed and the normal process execution would go on. And if you don't want to retry, then you want to access this explicit exception throwing, where let's say we are going to abort the process. And we can put any exception type.

Let's say we can give, you know any message to it and the type of exception that it that we want the program to throw. So unable to launch, right? And fail to launch application. After something like that, okay, we hit OK. And as you can see, it's a pretty sophisticated part. So there's gonna be no connection between any stages and the recovery stage. There's gonna be no Coming to the recover because that's how the jumping takes place there.

That's how the exception is caught by the recover stage. Right. So I'm gonna create the exception also explicitly, because if you remember once we use the application modeler to select the application, the executable file, which needs to be running. So I'm going to change the file name here is my CRM dot exe, I just changed the file name. So that way it won't be able to launch. If you just try it from here, you can see what error it is going to throw to try to launch it.

It's going to say that, you know, this is the by default exception message that has been thrown by the blue prism application. So that's all right. Let's try to run this program and see if you're able to get the exception handling in a way or not. So normal execution behavior. launching the same application No. So it went to the recover stage retry.

Yes, because the retry is still one. It's still less than three. It tried launching again. Did it work? No. They tried again.

It went back to the resume stage, trying to launch the CRM application again, he covered retry, yes. So it's gonna increment the value three, it's launching it again. And finally, it went back again to the recovery stage retry, no, and aborted the process. And you can see the exception type that you gave is unable to launch. And the exception detail that you provided is failed to launch application after three attempts. Right.

So that's a very decent sample use case of how exceptions are, do work. And we should also remember, in the exception stage, that the exception type is just plain text. Right? That's why it's not in double quotes, while the exception detail is An expression. As you can see, anytime you have this calculator, it's got to be an expression. So you have to take care of the data types that you're using, like this is a text.

So you need to have the double quotes if you're using this, right. So, to reiterate in here, if there any issues in any stage of the main process, the application is relaunched and the underlying stages are we executed, right. And any further stages, like we may put in this process flow are going to be executed if you know if the launching of the CRM application would have been successful. So if we created this, we directed our attention to the given exception message, and the user can now intervene to remediate the problem, right. Also, within the exception stage, there is the option to preserve the current exception, right. So if checked, can be observed that both exception type and exception detailed text boxes are grayed out.

This is because this exception indicates that the current exception is to be returned. And no new exception details are necessary. So consider a case where you'll need to read throw an exception. The only possible use cases would be when you are already dealing with an encountered exception. And based on some condition within the recovery mechanism, exception shall be rethought. So imagine this, right?

You got some issue with the logic of the CRM and in the recovery mechanism itself. You got the issue again, right. So that means you were already dealing with force exception, and now you have another exception, which is a part of this recovery mechanism. So you need to preserve the exception so that you can distinguish between the two. And you're returning an exception return that exception within the recovery mechanism of the first one by using the exception stage. So, in that case, we preserved the exception using this checkbox in here.

Right? So in other words, you're always gonna use the preserving, checkbox preserving the type and the detail of the current exception checkbox. Only when an exception is a part of a recovery mechanism, right outside, it wouldn't make any sense it would rather throw an error itself. Okay. Next, we're going to talk about exception bubbling. So exceptions are handled in sort of a hierarchical fashion, where it is first looked at locally.

And if no recovery mechanism is found, it moves upwards through the layers of business solution, where it finally reaches the main process page and causes the program to fail. So just understand the process that let's say That our CRM application was not able to be launched, right? Technically, this stage in the main process flow diagram, the launch CRM application, the only operation that it is performing is redirecting the flow of the program to the business object, right to this new business object and to its launch page. So it redirected and it started the execution. And it went to this launcher navigation stage. And some error was told, right.

So what happens is the program, it looks for the recovery mechanism here first, like locally within the business object, and if not, if not found, it will go one layer up, right, which is right here. So there could have been a case when you are let's say, referencing to a page within the process to do and that page internees referencing to a business object. So first, the error would be looked up at the business object level. If, if, of course, if that's the place where the error occurred. If not, it will go to the sub page within the process to do. And if it is not handled there as well, then it will bubble up to the main page.

That's how the exception bubbling takes place in this. And that's what this phenomena is called as well. Right and they may be an exception specific to a stage which is handled at the EU level. But if the recovery mechanism and itself encounters an error, we can explicitly throw it using the exception stage and it will go one level up the hierarchy and it will be handled accordingly. So this is how the exceptions are handled. Next, we're going to talk about exception blocks.

Exception blocks are used to set specific areas within a program which isolate stages and the And associates them with the explicit recover stages. So with no block, the recovery stage will handle any exception encountered on that page. So just imagine that right now, we only have in this main page, we only have one exception handling mechanism, right. So if there were other stages involved in this process, we have just put a note here. But any other process would have. If say, there would have been any error exception would have occurred, then it would have taken the same recovery mechanism, which is launching the application again, right?

There's a possibility that the launch was successful. And we were working on let's say, putting these sign in credentials, login credentials, right? Just take a hypothetical example. And you don't want to launch the application. Again, you would want to perform the login credentials of that operation again, right. So currently, this is the default recovery mechanism is what we call it and That's how we usually go ahead and like put the default recovery mechanism.

But to make a recovery mechanism or to get to associate a particular recovery mechanism with the stages within the process flow diagram, we use blocks, we call the exception block. Right. So in here, let's say we already have a pretty good decent working solution for you know, for the launch of the CRM application recovery mechanism. So what we're going to do is, let's extend this a little further, I'm going to show the example. Let's hope it takes a little lesser space. Actually, I'm gonna make it even more different.

So what it's gonna do is let's add an anchor stage out here. I'm gonna I'm just making this program look more neater, so it's not gonna make a difference right and here is the block this is like for the exception blocks that we were talking about, and we put in like this. So it's very important to have the stage within the main process flow or like at the beam level at the suffrage level or at the main page level anywhere the stage at the normal read normal mode, right, which runs in normal mode and the recovery stage under the same block. So that any exception that may occur in this stage is going to be caught by this recover mechanism and this recover stage. So let's say um, let's let's take this out, for now for the time being And suppose we have an action that's gonna login to the application, right?

Let's say our CRM application is an online one, and we will select the corresponding business object. And the action that needs to that is provided within the Bo level to log into the application is taking it hypothetically for now. And let's say if for this, if there is some error with the login process, then what I would simply do is I would have a separate recovery mechanism where no retries would be there, it would simply say that invalid credentials were there. So we throw an exception, because there's no point if the invalid there, the credentials are invalid, and they're gonna stay invalid, right? There's something wrong. Probably some upgrade happen in the back end and like trying the same ID and the password again, And again, it's not gonna solve the problem.

So you can simply throw the exception saying that there are invalid credentials. Right? Okay. And so you see what happened, recovery stage cannot have any incoming links. So that was totally my bad but this is definitely needs to be connected and we'll select a block. So anything that happens or anything that is wrong with the login stage will be handled here.

Let's say we may have other you know, for the companies Also in here, so we can put a note field just to, you know, we might have to perform other operations, rather than just launching and logging into an application. So you can put that that's totally up to you. And if we have a default recovery mechanism, then we can always, you know, like, put it separate from any of the blocks, right? by default. It's like any other exception, other than these two stages would be handled here. Right?

So, if you see, what you're gonna do is I'm taking another very decent example where I'm gonna put a data item. I'm gonna name it as exception detail. is of type text. Hit OK. Okay, I selected And in here, what you can do is if you see, within these predefined functions, we have separate functions for exceptions as well. And we simply use the exception detail based pretty easy, right?

This is This feature is really, really comes handy. So this function what it's going to do is it's going to provide the detail of the exception currently being recovered from here okay. And it will be stored in the exception detail data item. Okay. And what we can do is, we can simply resume this one and end this So now if you see if there's anything wrong with the launching of the CRM application, it will retry and everything, right. And if there is something wrong with the login of the application, it will take this route.

But we'll try to recover and recover is going to give this particular error or exception message. And if there is any other problem in like the main process flow other than these two stages, then it will be handled by the default recovery mechanism. Right. So currently, as we know, right, we have fixed the log launch CRM application here, and this should work. And the second one login to the application, there's no such stage. So the route that the process execution is going to take is going to be this recover to state where this exception would be thrown.

Right. And then we'll probably try to introduce another exception and see if the default one works. Good. already seen how the retry one is working. So let's close this and hit it, reset. And if you run this program, we are starting we launched in the CRM application that went just fine.

Log into the application recover and invalid credentials. So you see, see, the corresponding message has been displayed that the credentials are not valid, please check the login ID and your password. Right, which we haven't even provided. But I mean, that's the error message that we are throwing. Okay. Now, if you want to see how the default works, right, we simply click Close.

And we can probably take the block out. Right now. We're going to discuss about this as well, that once we have two different default recovery mechanisms, which one is going to be taken care of right? Let's see. So we start the process, the CRM application is launched, dug into this and we went to the recover to why because recover two was added to the process flow first. That's a very simple way that how that's how the blueprint program so even if you add recovered four or five 610, it's going to take recover to as the default error handling mechanism for any other stage.

And this block is actually not making any sense because like this block is denoting nothing, it's just you know, surrounding the log into application stage. So, if you want this to be you know, like this and just the recovery stage, because next once it catches in this recovery stage, then the process will be directed as per the length that is provided towards the exception stage. Okay, so, let's Ooh, let's create a let's create another exception and see See if the default one is working or not. And we have removed the link, right? Remove the link between the two. There's no ending stage, nothing at all.

So what we're going to do is, if anything happens here, it's gonna retry at this level. So just just see, let's let's try and see if this one works. Or if, like, if there is no link, after the Lord CRM application, will it go this route? Or will it go to the default route? Let's see. It went to this one, because there was an error at this stage, right?

The full processing, which includes the ending as well, didn't go through. So let's pause it. Let's reset it, close the CRM application. And what we're going to do is we're going to get a note stage so that it passes this particular application right at this particular stage. Let's reset it. Let's run it again.

If you'd see logic of serum application was successful, it went to The new node, which was some error, so it went to the recovery stage where it assigned the exception detail. And it ended and the Assign exception detail actually stored the exception detail in this data item, which is exception detail failed. Let's check this out. The current values failed to find stage length from stage note one, which gives a pretty good like default exception detail as well. Right so you can use that you can also explicitly throw an exception and get the exception detail corresponding to the message that you have given in your exception stage. And there are like those possibilities but it's really very, very important to have a decent or have very reliable bot for corporate work.

And to build these reliable bots you need to have an impeccable Exception Handling mechanism. Right and blocks in here. The provider Create visibility to the program by providing specific use cases and possible errors during each operation. They must be used extensively, yet meticulously to create the stable and robust software robot. So, I would recommend that you not try out different exception functions provided within the expression builders like the one that we have used and see their different capabilities, learn more about them and that way you get a pretty good hands on experience. And you can use them depending on what your business requirements are.

This is how the exception handling takes place within blue prism