Hey, I have conducted some tests on Global Exception Handler, since I haven’t used it in my projects before and I got some issues which I’m not certain about:
When present in a project, it catches all (or almost all, system.exception I believe) exceptions, including the ones in Try\Catch - is this a normall behavior?
I found under some other post, that if an activity throwing an error is alone (no sequence around) in Try\Catch, then it won’t trigger the Global Handler, I’ve tested and can confirm this.
Throw and Rethrow vs Global Handler - suppose we have a simple Try\Catch with some activity in a sequence inside, that is causing an error. In a Catch block (most generic - system.exception) we have a log and Rethrow.
When I was tracing the code, it had repeated 3 times the activity in a Try block, then went to Catch block, had also repeated it 3 times (3x Rethrow) and then went back to the begining of whole Try\Catch and started all over again… => it had stucked in kind of an unfinite loop, after some runs eventually it throw an error, see below:
In both cases the activity was executed 18 times! before an error finally occure.
The question is why Global Handler is trying to retry Rethrow or Throw activity, can this be somehow omitted?
Also why the execution of the program begins to retry whole activity (by whole I mean whole Try\Catch block even, if it’s in a Catch block or begins the whole Retry Scope Loop over again, or even retry the whole parent sequence, if the Throw activity is placed inside, without any surrounding container)?
I would like to repeat the problematic activity for 2 or 3 times in my projects but then, if an error is to be thrown (or Rethrown), I’d like to use “Continue” option from the Global Handler, but this is cousing an aditional loop and strange behavior, not sure is it a bug or I’m using it incorrectly, kindly advise.
Global exception handler will be triggered for any exception
When that happens…as per your setup…it is retrying twice if there is an exception and then continuing to next activity…but the next acticity also might be failing because of the previous activity failing and as whole of this is in try catch and in a rethrow…the same exception is getting rethrow and tried in multiple places
Basically global exception handler will be trigger always even when you rethorw because rethrow is nothing but catching an error and raising it again after doing some steps…so it still considers it as an error
Thanks for claryfication, but still wonder why the Try\Catch or Retry Scope was executed 18 times?
Per my understanding Try\Catch should be executed (with 2 times retry set in the Handler):
Try Block - 1st time (error raise) and then addition 2 times = 3 times total,
Catch Block - 1st time (Rethrow raise) and also 2 times per Handler retry option = 3 in total.
Giving 6 grand total, not 18, before an error was finally raise.
Same with Retry Scope with set to process 2 loops:
activity throwing an error for the first time and 2 times being retried that’s 3,
second loop same as above +3 = 6 times, not 18.
As I understand the mechanism of capturing the error and ignoring, aborting or retrying it, I do not understand, why option “Continue” (which should throw an error generated before the whole action) is re-starting whole activity\block\sequence instead of just throwing an error and end.
Ok, one thing just hit me - it seems that 18 comes from 6 times (from activities inside block\sequence being retried) x 3 times (from whole block of activities being retried) = 18, if I’m correct.
Not sure if there is anything to change in the logic, to avoid that number of times actions being retried (except deleting the Handler )
The second 6*3 is correct…because you gave continue when retry count is greater…instead if you give throw error the it wont retry…continue is like ignore the current error move to next activity
Yes, the Global Exception Handler is designed to catch exceptions at a higher level, including those outside of Try-Catch blocks. It’s meant to be a safety net that captures unhandled exceptions and provides a central place for exception handling and logging.
When an activity that throws an error is alone in a Try-Catch block, it might not trigger the Global Exception Handler directly. This is because exceptions within a Try-Catch are generally caught and handled within the scope of the Try-Catch block itself. The Global Exception Handler is mainly triggered when an exception propagates up the call stack beyond the scope of any local Try-Catch blocks.
The behaviour you’re observing where an activity is executed multiple times and then seems to get stuck in a loop can be due to how the retry and rethrow mechanisms work. The combination of Retry Scope and Rethrow within a Try-Catch block can lead to unexpected behaviour if not configured correctly. When an exception is rethrown inside a Retry Scope, it can trigger the retry mechanism of the Retry Scope. This can potentially lead to multiple retries of the same activity, causing the loop-like behaviour you described.
The “Continue” option in the Global Exception Handler allows the workflow to continue execution after handling the exception. However, in combination with Retry Scopes or rethrowing exceptions, it might not work as expected and could result in unintended behaviour, including repeated retries.
Hey, alright I believe below is the crucial info you have provided:
“The Global Exception Handler is mainly triggered when an exception propagates up the call stack[…]” - this error propagation is what I have observed and what was triggering multiple retry mechanism, bacause each parent sequence was throwing an error, causing Global Handler to retry it, until that error was handled or execution reached top sequence, retried it and throw finally an exception.
To avoid some of those retries, that I do not want to be executed, I did an assign activity in Global Hanlder:
answer = errorInfo.ActivityInfo.TypeName
and then in main If statement, I put a condition checking the source of the exception:
In that manner Global Hanlder won’t retry Throw\Rethrow\TryCatch\RetryScope and Sequnece themselves but other containers like Attach Window\Browser\Use Application\Browser will do which is what I needed.
Last update, I have tested above conditions used in Global Exception Hanlder and have fixed them a little. Final form as of now for main If statement in Handler is presented below:
In such form, I can retry single activities and whole containers like Use Application Browser\Attach Window etc., leaving Throw\Rethrow\Try\Retry mechanism as it is and also exclude standard Sequences from retry mechanism - only use them to “pass” the exception higher in Stack.
)
Anil_G
ashokkarale
Yoichi
mkankatala
The.giuso
Stef_99
Povilas_Jonikas
V_Roboto_V
adi.mehare
mateuszmacheta