Try/Catch's Finally Fix

Scenario: I’m trying to use Try/Catch how I would expect to do so in essentially any other scripting language: Try a bit of code that is likely to throw a few errors, catch nothing because the reframework is going to handle them, and use the finally block to do cleanup. I can do something silly, like capture all types of errors, save the error to a variable, check whether my error variable is not null, and then do my cleanup outside of the Try/Catch and throw the error again after I’m done to get around this, but that’s absolutely not how I would expect to have to use this.

Steps to reproduce: Create a Try Catch activity, Throw an error in the Try portion and Log Message in the Finally block. The message will not be logged.

Current Behavior: The Finally block is not being executed

Expected Behavior: Even in the case of an uncaught error, the Finally block should execute.

Studio/Robot/Orchestrator Version: 2018.4.4 (All three)

OS Version: Windows 10
Others if Relevant: (workflow, logs, .net version, service pack, etc):
Example of expected behavior: Test_FinallyExpected.xaml (5.8 KB)
Example of current behavior / workaround: Test_FinallyCurrent.xaml (9.2 KB)

The docs explicitly state that the finally block will be performed regardless of an error: Try Catch

Please see below post for a good summary of the issue:


Hi @dmccammond

I believe the quote below explains why it is not easy to change this bahaviour:

I’ve intentionally did not use words “fix it” as this seems to be an issue of how VB handles exceptions.

We can improve our documentation to make this more clear though.


The docs are edited with a more descriptive explanation of the bahaviour:

1 Like

I understand that it may be difficult to change, but I am willing to bet that this is going to be a continuing issue if it’s left as is. As @badita stated in the linked thread, if necessary, then it ought to be rewritten. Maybe giving a separate activity or updating the current Try/Catch with a property to designate how it will handle the finally block?

Since UiPath relies on Windows Workflow Foundation and ultimately .NET’s way of handling exceptions, a change is unlikely to happen. It would basically go against the very way that exception handling works - not just in .NET, but in most programming languages (here’s a good explanation for Java - yet, it’s the same in .NET).

> When an new exception is thrown in a catch block or finally block that will propagate out of that block, then the current exception will be aborted (and forgotten) as the new exception is propagated outward. The new exception starts unwinding up the stack just like any other exception, aborting out of the current block (the catch or finally block) and subject to any applicable catch or finally blocks along the way.

You could either do logging in a dedicated workflow and invoke it twice (one time when successful, the other time in catch) - alternatively, you could keep track of the error object and then log depending on its state in finally.

I’m sorry, but that’s just plain wrong. Even the languages you mentioned, Java and .NET, do not work how you state they do.

Every language I’ve used has the behavior that I’m referring to:

Several languages I’ve used don’t even have built-in finally blocks:

Just because C# does it does not make it a standard, and I would think that most people coming to this are not going to do so with C#'s implementation in mind. I’m serious when I say that this is likely going to be contested and that UiPath will continue to get this brought up without some sort of workaround that isn’t super clunky like the nested Try/Catch’s or catch all, rethrow outside suggestions.

1 Like

No, I am the one to apologize. I just double-checked, and you’re right - .NET handles the finally block exactly as you said it should:

1 Like