Hello,
The reason for this is that the catch block is not really what we assume it to be. You can better look at it as an “ignore exceptions” block, so if there is anything to do no matter how bad, let it happen here. so to better work your code you can have :
seq exOn-s
seq exOn-f
do
seq exOn-d
finally do
flag error
seq exOn-f
branch flag
– true seq
— pub.flow:throwExceptionForRetry
– false seq
This way you note that an error occured and you can act on it outside the ignore SEQ block. This could be looked on as a try-finally-react block. Good day.
Yemi,
I still don’t understand why throwExceptionForRetry gets invoked in the catch block, the document NEVER gets retried. Can you explain it in more detail? Thanks!
I had never noticed that if you throw ANY exception from within the “catch” block (ie. SEQUENCE Exit on DONE), the exception really never gets thrown. I think I just assumed it would because I’ve always thought of the “EXIT and signal FAILURE” step as the flow way of throwing an exception, and I know for a fact that in that case, the error does get thrown.
I guess if I had paid closer attention to the name, I would have realized that EXIT and signal FAILURE is more than just a “throw.” It’s actually an “EXIT first then throw an exception.” Right?
Hello,
I have to admit, what I posted does not logically make sense. I will update it here so you don’t mess up your work. Sorry for the possible errors.
Michael Deng,
You can call the second block a catch block. The thing though is that the error is initially thought to be general and then you alleviate work to the reaction block as a better “catch” which can handle re-throwing, new errors, and so forth. I will put some comments using C++/Java line notation.
seq exOn-s // anchor block, scope the try
– seq exOn-f // try block
— map // do something
– seq exOn-d // final block (you can consider it a catch block)
— map // do any clean up work, set flag for error
seq exOn-f // react block
– branch flag // what does the flag dictate
— true seq // we had an error
---- pub.flow:throwExceptionForRetry // let us try to signal this
— false seq // there was no error, good stuff
You see now it looks better. Before you could interpret it to have the react inside the try anchor, which would have let it to not be called. Good day.
The trouble is not with the exit on done’s behaviour… It is that everyone uses:
SEQUENCE (exit on success)
–SEQUENCE (exit on failure)
----- code here #1
----- code here #2
----- code here #3
–SEQUENCE (exit on done)
----- error code line #1
----- error code line #2
----- error code line #3
Which in java is the equivalent of doing:
try
{
//code here #1
//code here #2
//code here #3
}
catch (Exception e)
{
try { error line of code #1 } catch (Exception e) {}
try { error line of code #2 } catch (Exception e) {}
try { error line of code #3 } catch (Exception e) {}
}
Which is not what a java try-catch block is all about:
SEQUENCE (exit on success)
–SEQUENCE (exit on failure)
----- code here #1
----- code here #2
----- code here #3
–SEQUENCE (exit on done)
----- error code line #1
----- error code line #2
----- error code line #3
which corresponds to:
try
{
//code here #1
//code here #2
//code here #3
}
catch (Exception e)
{
// error line of code #1
// error line of code #2
// error line of code #3
}
Which is what a try catch is about… try-catch-finally is another matter… Perhaps that’s where the confusion about the exit on done stuff crept in.
arg… I didn’t update the 2nd flow code example, was having too much fun with the braces problem…
SEQUENCE (exit on success)
–SEQUENCE (exit on failure)
----- code here #1
----- code here #2
----- code here #3
–SEQUENCE (exit on FAILURE)
----- error code line #1
----- error code line #2
----- error code line #3
I would agree with you except that it doesn’t work that way. Even if you set the 3rd SEQUENCE to “Exit on FAILURE”, if an error occurs within that SEQUENCE, it will not get thrown.
I noticed this when I first saw that throwExceptionForRetry was not causing the document to be retried. My first stab at trying to fix the problem was to change the 3rd SEQUENCE to Exit on FAILURE, but it didn’t work either. Setting the 3rd SEQUENCE to Exit on FAILURE only causes it to stop executing as soon as an error is found.
Just try the following simple code:
SEQUENCE (Exit on SUCCESS)
SEQUENCE (Exit on FAILURE)
— Divide by Zero
SEQUENCE (Exit on FAILURE)
— Divide by Zero
You will see that an exception is never thrown, whereas in Java it would.
$default seq (exon-f) ## catch body ## {}
– map ## divide by zero
It seems that there must be a disjoint between the sequence that sets the error and sequence the act on the error if we want the catch itself to allow for throwing errors. It you want this caught and never exposed, the ways shown by Nathan Lee are fine. Good day.
aah yeah, guess it does ignore it in the catch block… which makes sense really come to think of it. I’ve never wrapped up the whole handler thing in a try-catch, it’s usual practice to return flags with services. Guess the set flag, then branch and throw exception is the way to do then.
