Local Error Handling: Try-Catch-Finally Blocks

[00:03] (external link, opens in new tab) What if we want not just global error handling like on failure here but we want if there's an error to continue. Well, one way that we can continue is to specifically on an action to say ignore failure. Another option is specifically on the sub action here in download page. We can say ignore failure or we can say you know what for every one of these pages if it fails don't worry about it we have special actions if we look for

[00:33] (external link, opens in new tab) Flow there's flow control category here and in the flow control category one of the things we have is try catch finally and end and many more things here as you can see But the nicest thing is I can right click on this action or a bunch of actions say refactor wrap with try catch and basically try catch actions are if you move things under them

[01:06] (external link, opens in new tab) They those things can then be caught under the catch action. So I can say you know what in case of on failure I'm going to do all these things too. Copy and paste and move them over under the catchphrase. So now what's going to happen is that for each one of those things even if it fails I will continue on to the next thing.

[01:39] (external link, opens in new tab) So, let me just show you that if I switch the order, CNN will actually still run because there's an error here in the Google stuff if you remember. So, now things should be able to run. Now you can see here if I try to run it and I say play, you see host has not been set for the email stuff. So, I'm not going to send the email here. That's for another day. And in the on failure, I'm not going to send the email.

[02:12] (external link, opens in new tab) That's for another day. You can see I'm I'm doing the same thing twice, which I don't like. So maybe what I really want is to extract these two into their own function that says handle a failure because I might want to do the same thing in multiple ways. Maybe, maybe not. So I can say, you know what, in case of the catch here, I can refactor, move to an action list. It says handle any failure.

[02:47] (external link, opens in new tab) And now when I when I try to download any page, it will run handle any failure in case it catches anything. And on on failure, I want to replace that with just calling an action list. So I'm going to go to the search and say action list. And I'm going to run action list. Here I'm going to choose handle any failure and that's it. So now handle any failure will be called either by download page or on failure. But if I want to change how I handle all these things, I only have to change one place.

[03:20] (external link, opens in new tab) Now maybe when you write your scripts, you want to have different handling for global and specifically local. That's okay too. We can even put a try finally so that no matter what happens, we always have logging. For example, I can choose all these things, select them and say rightclick, refactor, wrap with try finally. So then even if one of them fails regardless

[03:50] (external link, opens in new tab) At the end I'm going to have again calling an action list handle any failure. So now what happens is that all these things will happen and regardless I'm going to get that log file which really is something that I would want. Maybe I should rename this to something better. for example, rename and say export logs.

[04:23] (external link, opens in new tab) Maybe that's a better name because on try catch I want to export the logs and regardless I want to export the logs no matter what. So even if there's a success I want to see the logs and that's very important. The logs will be exported no matter what. But the try finally here or try catch here will allow this action to run even if this one fails. If I try to run things now the first one fails the other one completes. So that's still exporting the log file that one actually completed.

[04:55] (external link, opens in new tab) If I go to you see then now it looks green because there was a try catch. So if I go to download page, you'll see that it completed twice and this was skipped but was also completed once. If I go to the log file, I can see in the try where are you?

[05:25] (external link, opens in new tab) Auto collapse show all errors. There's an HTTP get file. There was an error there. But I want to show it in the context. So now you see there's download page. There was a try and then it got caught and that was executed. So we can use try catch finally to have better control more fine grain control over what happens when a specific action runs or when something specifically fully runs.

[05:58] (external link, opens in new tab) Now, this is also a good candidate when I have these big things. Although it's kind of readable already, I would still rather do this extract all these things into another action list that says do main logic or something because I want to show that there's a main logic and then there's and exporting logs no matter what. And again, this is up to you, but probably this is what I would start doing and that is start process or something like this. refactor, extract a new action list, and that is start

[06:33] (external link, opens in new tab) Main logic. And again, I'm not sure yet. Maybe it's still pretty simple. Maybe not. Maybe instead what I'd rather do is that all of these things should just be wrapped in their own action group. So there's this action group and we can rename it to from downloading web pages to basically

[07:04] (external link, opens in new tab) Fill up the main output file. Maybe maybe not. Maybe I can look at it like this and that's good enough too. It's our choice and that's what I like. I can look at this. I can drill down or not, but it's very easy for me to see or even disable the whole group if I wanted to.