If you run it, it will just rename the excel file. But if you open the file in Excel to lock the file in place, before running the script - GlobalHandler will take over the exception handling despite Move activity being wrapped in a TryCatch.
If you disable GlobalHandler - the exception is correctly handled by TryCatch.
Please help me understand why this is happening. I am lost.
I went through the solution you have here and have an understanding about the problem you are facing here.
So, let’s first take a look at what global exception handler does. When executing a workflow, if any activity runs into an error, the global exception handler will basically try to retry the execution of the same activity to see whether a retry would do a successful execution of the activity. However, you can configure the global handler to either retry or to abort the execution. So how you have configured it is to abort the entire execution in case of an error. So it will not execute the catch segment of the try catch activity.
So ideally, your global handler should retry the first before the abort. So have some retry attempts as well.
Yes… in your case it’s true. But there are things that cannot be handled through try catch. Imagine a scenario where you have a slow website which you are trying to extract some data from. While you do the extract imagine the page is loading, and so your get text activity is running into an error. In such scenarios, it is good to have a retry attempt on the same activity rather than throwing an error in try catch. So global handler will retry and check whether it can try to get the data without running into an error.
Such cases, it is good to have the global handler. it is mostly useful to handle slow timeouts and kind of situations.
yes. That’s what i’m talking about. So retry will retry the same. And still you have the abort in place. in such case, it will still abort
Oh well. I am not saying that GlobalHandler shouldn’t be used and I see the use cases for it - that’s why I am using it in other projects. But recently I came across this issue and I can’t understand why it behaves incorrectly in this exact case.
yeah… for that you got to configure it as required. I changed it a bit. Use this global handler file in yours. It will first retry until the specified retry count is reached. Once the out is reach, it will not abort. But will execute the catch segment of the workflow…
It works with the GlobalHandler file you provided, but still, this doesn’t answer the question “why?”.
Again, as I understand, If I manage certain exception within Try Catch, then GlobalHandler shouldn’t even be called if that exception is raised. In my case I have “IOException” exception managed but GlobalHandler still executes. I am trying to understand if I am wrong about how it should behave or it indeed behaves incorrectly.
There is another topic that explains how it works:
Thanks for the video, but it explains everything EXCEPT the question of this topic
Actually, I logged a support ticket and this is a summary of their answer:
===============
When using the Global Exception Handler with a project that includes a Try Catch, if the activity which encounters an error is placed in a Sequence inside the Try container then the Global Exception Handler will be executed.
If you do not want the Global Exception Handler to be executed for an activity inside Try container then make sure that the activity is not placed inside any Sequence => it is the only one activity in the Try container.
===============
Support engineer agreed with me that this behavior is not like any other programming languages with Try Catch constructs, and he logged a feedback ticket to the production team.