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.
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:
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.
Several languages I’ve used don’t even have built-in finally blocks: Lua C++
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.
I posted in the other thread linked first.
If you can make this work the way it should, please do so
If you cant, then please remove the Finally from the toolset and it has caused me no end of grief assuming it would do what it does in every other language
Anil_G
jast1631
donghai
gulsheen_kaur1