Chapter 13 error handling. In this chapter, we'll be going through an overview of error handling mechanisms. We will discuss what is debugging within UiPath. We'll go with major error reasons as to why the error comes up. And we're also gonna talk about try catches and finally blocks. Okay, overview.

No matter how good your workflow is, or how many use case scenarios you could think of implementing, there are always chances that an abnormal condition may arise and disrupt the process flow. This unwanted behavior, if not properly managed, could lead to a chain of problems within interdependent systems if about. The workflow in turn should be made capable enough to be able to debug the problem and tackle it in the best way possible. Imagine you're trying to access a web application using your login credentials. But somehow you're not able to get in. If done manually, right like without the bot, I'm sure that you will try logging in a couple of times before concluding that the credentials are invalid.

Finally, if you're still unable to log in, you will probably send out an email to the concerned administrator to look into this for you. You should design your workflow in pretty much the same fashion as well. This increases the reliability on our pa bot, and makes the overall process robust. UiPath has inbuilt features to debug and encountered error along with the activities to specifically mention if there is a possibility for an error in certain part of a workflow. If the error occurs, it is subsequently managed as a different piece of workflow sequence. This ad hoc these ad hoc errors that occur at runtime are also called exceptions in programming world Quick additional information is that it has been mentioned before, to use proper naming convention for activities used within the workflow right?

This practice becomes very, very useful in debugging the workflow, providing the ability to track and debug issues faster, along with making overall workflow comprehensible to other developers. debugging. There are different ways in which UiPath can handle the occurrence of an error, debugging the program by traversing through it step by step and recognizing the specific area within process. Where error occurs is the foremost step. This capability is facilitated by the debug option provided in UiPath. So you can see under the execute ribbon, right, the debug is there.

And you can also press the f7 key as the shortcut for this. And you can start the debugging And once you do that, because we don't have any activities yet, so nothing has been shown, but it is gonna start off what we call as a dry run, it is going to start off with dry run for the program alongside the target application where operations are being performed. And the corresponding activities of the workflow are highlighted, providing a focus point to the developer to understand the execution flow and its corresponding action. Right. So let's let's take a quick example in this. Suppose we have a notepad open file open and and let's create a quick basic recording session to Hello empty field just for this one.

Then, click on format no click on form Okay, to start off with the bold. Start off with the Verdana font system, click OK. And then in here, press space and write down word. There's no empty checkbox this time. Right? Let's close this. Save and Exit.

And create connect this to the start node. So now as you can see, right, the there is a sequence that is involved in here. And let's mess it up a little bit, just to create an unnecessary issue. Right Hmm. I'm not sure if this still gonna work or not, we just change the selector a little bit. And what we can do is we can just give it a shot and see if it works.

I just ran the program. So it didn't click on the format. And because of that, the font and all these underlying activities couldn't also be executed. Right? We just made in fabricated error as, as we can say. So, let the box finish processing I'm going to change the timeout as well, because we don't want to wait for 30 seconds to see the operation, this fabricated error.

Okay, so it says that it cannot find this UI element, which means we were able to successfully mess up The Excel it could find the format but couldn't find the font. But what we are going to do is we're going to start up the debugger mode. Right? And once we do that, so let me actually start that again, just so it becomes more easier to understand. So what we are going to do is we started the debug mode again and see yellow activity. So menu format is clicked and now it's in this menu, item font.

It is highlighting the activity within the workflow, which is currently is being tried to be executed upon and it's not gonna do that because it's not able to Find a corresponding selector. What I'm gonna do is just five times in five seconds, it's, it's the maximum time. It's kind of wait, right? Let's do this. So, we are able to find that you know which activity is like we which activity is being highlighted using the debugger mode. And that way, we can always compare what the operation is being performed on on the target application and what is being executed in the workflow.

Right. Okay. Another option that we have to highlight the UI elements. It's like through this one, right? If you don't want to, if you want to highlight the elements as well, and the target application, right, then you can do that you want to log activities. I'm going to show you where the log up to These are two places one is the output panel and the other one is the log files that are created in within the system every time like a program is executed, so, let's see.

And it will also show which you know, he is working on. So red point like this is the Hello then selecting this one. So the format is taken wrong, right. Did you see that the format was being taken as this this particular area, which is not the case, we don't want to click here we want to click on the format. Let's select these selectors back. Okay.

And let's run this again. Just to see how it works. We've started the debug mode again. You're gonna see this one here farming is here red, then font is here, yellow is also there in the workflow. Here is the font type name, I mean, and a perfect world is written and done. So, that's actually very handy when you know, in large, complex automations.

You don't want to, you know, like, say go through the like each and every activity that you have used probably you've been working on this since past five months, you don't want to go back to each and every activity go through it, what has been provided to it, and then you know, sort of try to find the error or pinpoint where the error is going to be. So that's how we can do it using the debugger. So next is Properties Inspector, or we call it local panel as well. Properties Inspector is the panel available usually next to the output console that provides runtime dynamically generated information Regarding the local variables, and any data elements workflow it's executing upon, we can keep a track of the current values stored in variables. We can verify if the data operations acting on them or as per the business logic implementation, we can also verify the selected values taken from the elements of an external application are correctly identified or not.

And all can be done in between the execution flow. So to show how this looks like, I'm going to run the same program again. And I'm going to show you because I've already maximized it to decent extent. So there it is the local panel, and you see that it's identifying this particular using the notepad. I mean, the selector is here. There are some data of value variables.

Well, there is an exception here. So that's how the local panels are used, and they can be used to dynamically check during the runtime itself where The data element is being read correctly or not. Right. Next is the activities log. So, you know, while running the debugger mode, right, the output panel also displays the log of process activities, let's say something like this, right? It provides a clear background of the activities that have been executed so far in the work in the workflow and AIDS in verifying the direction of program flow.

Activities log at any particular instant, may appear somewhat, you know, is like what I've shown in here. Okay, and using all these tools is the first step of debugging that is to recognize the problem area and understand the reasoning behind it, you know, is performed then there are additional features to aid in the process, like slow step, right. So right now, even in the debugger mode, there's a possibility that you may think that this works for is running pretty fast. So for that, what you can do is you can start the slow step. And that way once you're debugging, right, and let's This is how the local span also looks like. It's going to take each and every step slowly, you know, typing it into it's going to the format, it's going to the font slowly now it's going to the font.

Now it's, it's, it has got to the font window itself, here it is choosing the font style and the names and everything. Right and you press the OK button and here you press like right down the world text and done, the process is finished. And the locals panel is also closed. Right? So slow step can help you in recognizing that, you know, sometimes that you know in some cases, if the process is way too fast, there's a possibility The UI element has not appeared yet in the in the local desktop application or could be web application as well. So you can slow it down and debug it to see if that's the issue.

If that is the case, you can definitely use a find image activity or I don't know increase or decrease the timeout parameter within the Properties panel to make sure the limit appears at all times or most of the times. Next is validate right. So this option checks if there are any validation errors like mandatory properties or are set up. blank blank input output values include expression syntax, you know, sometimes people use like, like, they created a dynamically generated variable which is of generic type. And they didn't change it to string type and they are trying to concatenate or some some string function they're trying to implement on it. This process Delete might not work because due to some implicit data conversion issues.

So those are the things that can validate and let you know if something needs to be changed right strictly from the compiler or from compiling the process perspective, not the runtime issues, because those errors occur like as a runtime, so you cannot work much on that, unless, you know, other than identifying the selectors correctly from the beginning itself or making sure your logic is implemented correctly. breakpoints, okay, this is a very important feature, right? It this option puts an intentional pause on the program execution during the debug mode. Once the program reaches this point, the execution stops, but can be resumed upon rerun. So this helps the developers in maintaining the program logic intact by dividing the workflow into sub parts and breaking them into like one after the other process for further execution. So, what it's going to do is say, you know, this is gonna break the execution flow suppose you want to just write down Hello or just here is what the right sign appeared, right?

It started in the debug mode, and Hello, and the program stuff. Nothing is gonna happen unless you either rerun it, or remove the debug point or the breakpoint from here or so on. Right. Okay. So usually that is how the locals look like, okay? That's what breakpoints do then we have step into step into gets to the nest next activity and performs only the first iteration.

So step two is like let's say if the next activity is first loop is a fault. each loop or any loop whatsoever, right? Then it is gonna do just one iteration, let's say it is it's gonna iterate 10 times that loop. So step into performs the activity only one time. So that's the difference between step into and step over, step over what it's going to do is, it's not going to divide the next activity into sub activities, right step into is gonna perform the sub activity also only like the first sub activity within the next activity. For step over, it's going to complete this whole activity.

So let's say if it was a loop, which was supposed to iterate 10 times, it would do all the 10 iterations and it would move like to the end state of the next activity. That way, the further you know any other activities, which are probably listed after the next activity can be processed based on direct execution step into step over whatever. right that's a quick difference between step into and step over and That's how we usually use the debug mode, which is there within the execute ribbon to recognize the problem and work upon it as well. Next, major error reasons. Since RPA tools interact a lot with the external applications for automation purposes. Other than the debugging tools, there are quite a few other techniques to resolve the problems we may encounter and continue with proper workflow execution.

First, and the most common issue we usually face is the selector not being able to identify the UI element correctly, right available to the part. So the error note, as you can see, would look something like we have shown that before as well. But see, we take this out, application format and menu bar and we try to run this to a point, we don't need anything at all. Okay, so we didn't mess up with the selector yet. Okay. I'm not sure why that happened, but maybe I was in the debugger mode.

So that's why the changes didn't take place. I just saved it. ran this again. And let's see. So yeah, format didn't click correctly on the menu bar format option. Okay, so this is how usually, a selected error looks like, you know, it's gonna say that message cannot find the UI element corresponding to this selector and the selectors, values also provided.

Okay. So this error could be The possibility of this reason this error could be because of two reasons. At first, the selector has some static attributes for dynamic content like file name, date, type, etc, which changes with every workflow execution. And such situation can be remediated by looking at the selector of the UI element, and properly modifying it using wildcards or replacing the attributes altogether. And we have discussed this in greater detail, so we're not gonna go back into it. The second reason, a possible reason could be that there's some application that's hindering the visibility of the UI element of target application.

Right? Suppose you want your this to be visible, but somehow you have another, you know, let's say better it is desktop. You have another window open. That's That's gonna hinder this application, maybe some other bodies working on the same machine, that could be a possible case, which is hindering this overall view of this application where you know, you have all these burdens. And, of course, somehow the input or the output, whichever activity you're working on, doesn't support background processing. Because if it does, you know, it would work out fine.

So, I guess I pretty much give the answer as well, that you know, for the sort of hindrance of activities, the possible remediation techniques are to use the background processes within the workflow so that you can communicate either through messages or through simulate type actions or something like that. Or you make sure that none of the other applications are open that could hinder the visibility of the target application. Right. Okay, perfect. So, another common reason that your bot may work most of the times but not always is because of the in capability of target application to keep up with the operational pace of UiPath. In a manual scenario, once you provide an input, say your login credentials to a system, you wait for a couple of minutes to see if the page is loaded successfully.

And then you start performing the other operations UiPath workflow on completing one activity operations starts looking for the UI elements to interact with the target application provided in the subsequent activity right and if delayed longer, it may reach the timeout period causing an abrupt termination or unusual behavior which is not what we want. So if you know these timing and synchronization issues can be tackled using additional activities within the workflow as we just talked about like defined element or element exists or find image etc. Right? And based on these activities, our execution flow could be diverted from one sequence to another. Say you use element exists activity on a target application, which results in a boolean value like true, if else if the element exists, else false. Subsequently, we can use a Ctrl F statement that puts the steps to be followed next, right if the element is found, or retry or exit the program if it doesn't.

So that's a very, I would say sophisticated way to handle the errors in real life scenario. Right? These programs can act according to the state of the application without being interrupted unexpectedly. So the last topic we're going to talk about in this chapter is try catches and finally blocks. In most situations, you will want to be able to detect the errors as soon as they come forth. You want to enable the bot to perform actions Based on the error type, and on mending the situation, continue with the workflow.

In case the issue requires manual intervention, the bot should be able to notify the concerned user as a recovery mechanism, which serves a better purpose than simply ending the workflow hastily. In UiPath, we can enclose activities within try catches, and optional finally blocks to achieve this result. So, let's say within the same recording sequence, which we had where we are working on the notepad document, let's say this activity, right is causing some problems. That means there is a possibility that there is going to be some error, or there's a possibility that there might be an error in this in this activity. So what we can do is we can simply right click on it and be surrounded with a try catch block. Once we do that, we get the activity within the try block, the one that we selected, so the activities that need to be monitored for errors are contained in this tribal app.

And if the error occurs, it will be handled in the corresponding catches block. So, see in here we have catches, which means there could be multiple catches that we can include and the catches on occurrence of an error within activities enclosed in the try block, the activities from the catches block are executed. So, single catches block can include many different types of errors, which are also called exceptions. And hence, the term is used in here to look for, you know specific exception type, we need to check the error note that is generated by the UI path. So, if you remember once we when we messed up the selector right for the Format menu, then we were getting an error type also in the error note. So, that's where it comes into play, you know, you add a catch and once you add a catch you select the type of exception it is To create the artists possible to be creating.

So like, it could be an argument exception, it could be null reference exception, it couldn't be an input output exception, invalid operation exception. And there are like a lot of types which you can browse for. But the system not exception covers all the exceptions, which means any exception is going to happen or the body's gonna encounter that would be caught. So suppose we take the exception, the system, not exception. And once we select the exception type, we get the panel to write the activities within it. So let's say if any error occurs.

You want to say you want to print a message box, saying, Oh my god, exception occurred. Something like that, right? Could be anything. If you want, you could probably just close the application and not continue with the other activities between Cuz I don't know depends on the criticality of what this activity is or if you want to retry, you can try re reopening or re executing the application itself or depends on the recovery mechanism that has been provided as the business requirement to you, right. So, this pretty much covers this and finally block the activities in the finally block are executed after try catch blocks finish executing it is optional to have activities in this one. But it is worth noting that no matter if an error occurred in try block or not, activities within finally block will always get executed.

Right. So you can probably write down a log that says that, you know, yes, we found we monitored the format. UI element exists existence or you can just, you know, something like that or you could be any activity that needs to execute no matter what, then you add that in the finally block itself. Right? And say if the error occurs, you still wouldn't want to continue with this. So what you can do is probably just from the logical sense, I'm saying this right all these activities depend on the font container I would say right?

So, what you do is you can probably cut it and paste it in the try block itself. Why? Because that way, you will always make sure that or you could have added a sequence itself in here. Something like that. And you dig the sequence itself. This is the sequence where did it go?

I want this. Yeah, control x, and you're pasting it in the try block. So any errors that may occur in this whole sequence, which includes like this format, let's mess up this selector again. Oh, it's already messed up. Okay. So now, instead of, you know, giving the error note or something, we have given a customized error note that says that oh my god, the exception occurred or something like that.

Right. Let's try and run this and we'll see how it works. Hello is written and then it's looking For the format didn't find it and oh my god exception occurred right. So that means the corresponding catches block actually caught the exception. And this is the error handling mechanism that we have chosen in here. So, that's the corresponding message that has been displayed in here, we could have usually what we do is we send out and but the world did happen because after the try catch block, we put the typing of world activity outside the try catch.

So that means that also did happen, what we could have done is the more better approach would have been that we want the word data to be in the notepad document. So we could have put that in the finally block as well. Right. So this is how we use the try catch block. And all exceptions have been caught. We can, you know, we should be able to find what sort of exceptions one particular activity can bossy encounter.

And there, there could be like subsequent recovery mechanisms for all of those exceptions. So that's how it is, as I was saying in actual projects, usually what happens is if a cyst if an activity is very crucial, then usually this user send the email activity like we discussed in the last, you know, chapter that, you know, send out the message that you know, some like this sort of exception occurred and please check the system yourself and probably start the program again or something like that. So, that is how we handle any errors that we may encounter and make the program more make our workflow more reliable and robust. Alright,