Try-Catch Finally improvement

Hi Alexandru! Actually it is the workflow foundation behaviour and not .NET. Let’s not mix the language with the runtime.

The comparison between worflow foundation and C# it makes more sense, just the video example is not the best. In C# the finally block is executed 100% with no discussion (and let’s ignore the case where you thro exception in the finally)

Hence, if you will replace MessageBox with Console.WriteLine you will notice that I am right. The reason you don’t see the MessageBox is another topic.

For all others, I made a video about how you do proper exception handling in UiPath.
The first part is just to clarify the try-catch behavior:

and in the second part, I show how you fix the UiPath behavior:


I know its an old topic. I have read the different explanations here. Since I’m facing the same issue and I thought, as most of people here, that ‘Finally block’ should be executed in both scenarios (with and without errors). I tried to reproduce your example and as it was already explained the ‘Finally block’ is executed at the higher level (which means that we need to have 2 Try catch at 2 levels) as you can see in the attached pictures.

So, I think for your example, you need to put the ‘write line’ inside ‘Finally’ within the ‘Main sequence’, not in the invoked sequence.

Well, honestly I don’t think that i totally got the goal behind this double Try Catches approach, if someone here can explain it with an example that would be cool.

Example Result

Why should Finally be executed no matter what?

If you have code you want executed no matter what, put it after the Try/Catch. Making Finally execute whether an exception occurs or not makes it useless. If they renamed it “If No Exception” would that make more sense? Because that’s what it’s for. If there’s an exception, the Catch block is executed. If no exception, execute the Finally block. This is used for things like returning your application to the correct state for the next transaction. If there is an exception, your “return to starting state” steps will likely be different than if there is not an exception.

I totally understand your questioning. But, actually I do have a situation where I need to perform actions in the ‘Finally block’ we can call them: “cleaning actions” (like: close and delete an Excel file in both scenarios). I know that there’s away to do so! But the matter here is efficiency (having a short and clean code).

For our example: I needed to put (close/delete Excel activities) 3 times (2 within the ‘Catches’ block which I have 2 exception types) and (1 within the ‘Finally’ block).

I believe that it will be more convenient to have to put those actions just in one place. So, if I put those actions (as you suggested after the try catch) and one of those exceptions are thrown the “cleaning actions” won’t be executed, unless, if I have a nested double try catches (as you can see in the example I sent).

Just put that code after the Try/Catch in its own Sequence. Then it executes every time, regardless of whether the Try/Catch completes with or without an exception.

Yes, they will.

The Sequence is executed no matter what happens in the Try/Catch, as long as you properly handle any exceptions.


I have trying it! and believe me, ‘Nothing’ is executed after the TryCatch activity, if an Exception is caught and thrown, unless with a nested TryCatches.

We can see in the example: the ‘write line:child sequence ends’ placed after TryCatch activity didn’t executed once the exception was caught and thrown. Only, the ‘write line: Proceed to next actions…’ placed within the higher TryCatch ‘Finally’ block is executed.

So the question is: "Why in the high level TryCatch activity (in the main sequence) the ‘Finally’ block is executed even if an exception was thrown? and why it didn’t for the other TryCatch activity within the ‘Child sequence’?

It seems to me quite confusing this logic! Unless there’s a real benefit to have to use 2 nested TryCatches and that’s why I asked for an example.

That is wrong, sorry. The entire point to a Try/Catch is to catch exceptions, handle them, and continue. If your automation is faulting at the Try/Catch you aren’t use the Try/Catch properly. Do you have a Throw in your Catch block(s)?

Edit: I see you have a Rethrow in your Catch block. Why? That’s why your automation isn’t working the way you want.

Yes, I have a throw in the ‘Catches’ block with 2 exceptions types (BusinessException and system Exception) and once TryCatch caught an error its thrown to the higher level but without executing the action placed after that TryCatch (as you’re suggesting) it stops in the ‘Catches’ block.

The ‘Rethrow’ is just for the example, for simulating the Error (the scenario where an error occur within the ‘Try’ block)!

@Amjad_AGHZAF, just use two TryCatches…

C# code as an example:

		// your stuff
	catch(BusinessRuleException e)
		// your business rule exception stuff
	catch(Exception e)
		// your any other type of exception stuff
catch(Exception e)
    // don't do anything here
  // your clean up stuff

Thanks @alexandretperez, I managed by using just one TryCatch with IF. :+1:

There’s your problem. Throws go in the Try block, so they’re caught by the Catch block.

Imagine my disbelief writing this 6 years later. There’s nothing more to add to the topic than the resources and explanations that have already been posted in this thread, yet UiPath will not implement this feature properly.

This is a BUG if I’ve ever seen one. The way it currently works is against programming principles.

I’m writing this comment hoping that if I bump this post, maybe someone will finally schedule a fixing date for this issue.