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 Bedu

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!

Yemi,

Thanks for the response.

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?

By the way, before I got your response, I created a ticket with webMethods about this. They sent me two links, which provide basically the same solution as the one discussed here. Here are the links in case any of you are interested:
[url=“http://advantage.webmethods.com/cgi-bin/advantage/main.jsp?w=0&targChanId=knowledgebase&oid=1-55538222”]http://advantage.webmethods.com/cgi-bin/advantage/main.jsp?w=0&targChanId=knowledgebase&oid=1-55538222[/url]
[url=“http://advantage.webmethods.com/article/?id=1611547540”]http://advantage.webmethods.com/article/?id=1611547540[/url]

Thanks,
Percio

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.

Yemi Bedu

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.

regards,
Nathan

PS couldn’t use the pre tag to stop the formatting getting messed up as it mucked up the closing braces in the java code… Hmm…

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

try again,
Nathan Lee

Nate,

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.

Thanks,
Percio

Hello,
this would probably be a nice way of doing things:

seq (exon-s) ## anchor

• seq (exon-f) ## try ## try{}
  – map ## divide by zero
• seq (exon-f) ## catch head ## catch (Exception e)
  – map [exception-type=getLastError]
  branch exception-type
• $null seq (exon-f) ## nothing to do
• $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.

Yemi Bedu

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.

Nath