| Author |
Message
|
| Senthamizh |
 Posted: Mon Feb 20, 2012 4:50 am Post subject: Identify Exception Type |
 |
|
Apprentice
Joined: 21 Dec 2009
Posts: 47
|
Hi,
I would like to know if there is a way to identify the exception type (Recoverable, parser, Database, cast, Security etc)
In my current exception handling, i would like to process the Recoverable exception message from catch terminal but i do not want to process the same messgae again from the failure terminal of the input node of the flow once its thrown again from the catch terminal.
I tried to get the value of the field by FIELDVALUE function and also checked if the field InputExceptionList.RecoverableException exists, but i got negative result eventhough the RecoverableException exisits.
Could someone help me on this. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Feb 20, 2012 6:36 am Post subject: Re: Identify Exception Type |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Senthamizh wrote: |
| I would like to know if there is a way to identify the exception type (Recoverable, parser, Database, cast, Security etc) |
The children of the exception list identify the exception type.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Mon Feb 20, 2012 6:52 am Post subject: Re: Identify Exception Type |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
If exRef is your reference to the (top) of the exception tree, then you can find your exception type (exType) with looping down the exception tree:
| Code: |
DECLARE exType CHAR;
WHILE( FIELDNAME(exRef.*[<]) = 'RecoverableException' OR FIELDNAME(exRef.*[<]) = 'ParserException' OR FIELDNAME(exRef.*[<]) = 'DatabaseException' OR FIELDNAME(exRef.*[<]) = 'UserException' OR FIELDNAME(exRef.*[<]) = 'ConvertionException' ) DO
SET exType = FIELDNAME( exRef.*[<] );
MOVE exRef TO exRef.*[<];
END WHILE; |
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| Esa |
| Posted: Mon Feb 20, 2012 7:57 am Post subject: Re: Identify Exception Type |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| Senthamizh wrote: |
In my current exception handling, i would like to process the Recoverable exception message from catch terminal but i do not want to process the same messgae again from the failure terminal of the input node of the flow once its thrown again from the catch terminal.
|
I wonder if you are aware that the exception that MQInput node propagates to failure terminal is not the same one that was propagated to catch terminal...
As a general rule a node propagates to failure terminal when an exception happens within that node. Downstream exceptions are catched and propagated to catch terminal, if the node has one and it's wired.
Typical exceptions that happen during execution of an MQInput node are
validation exceptions and the exception thrown when the node has read a message that has previously been backed out and has exeeded the input queues backout treshold. In the latter case the exception just tells that the message has been backed out. The original exception ceased to exist the moment the message was backed out.
Do some debugging and you will see what is happening. If I have understood correctly what you are trying to do, your scenario is based on false assumptions. |
|
| Back to top |
|
|
| Senthamizh |
| Posted: Mon Feb 20, 2012 9:17 am Post subject: |
|
|
Apprentice
Joined: 21 Dec 2009
Posts: 47
|
@mqiuser
Thanks for the piece of code, FIELDNAME function didnt stirke my mind....
@Esa
I am aware that the exception propagated to failure terminal is not the same as the one propagated to catch, but then in our flow, we connect both the catch and failure to a common error handling mechanism. And when the message is propaged to the catch, we handle it and also explicitly throw an error to backout the message and to write the error in syslog. Since the message is thrown again, the messgae gets backed out and then comes via failure terminal of the input node in which case, we need not want to process the messgae again. But in-case of parser exception that happenn during validation in the input node, we would like to process the messgae that come through failure terminal. |
|
| Back to top |
|
|
| Esa |
| Posted: Mon Feb 20, 2012 1:24 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
Senthamizh, I am happy to have been wrong.
But you never know. Once I met a customer who had wired their exception handling routine from the failure terminal. Or actually it was a consultant from a well-known consultancy company that had done it for them, so the wouldn't believe me when I said it was not the best solution. They were quite happy with their exceptions 
But that was over five years ago. |
|
| Back to top |
|
|
| whydieanut |
| Posted: Tue Feb 21, 2012 12:16 am Post subject: |
|
|
Disciple
Joined: 02 Apr 2010
Posts: 186
|
How about checking the BackOut Count of the message in your common Error Handler?
Messages that have gone to the Catch terminal and purposely thrown would have BO Count > 0, while messages sent directly to the Failure terminal would have BO = 0
Someone please correct me if I am wrong... |
|
| Back to top |
|
|
| Esa |
| Posted: Tue Feb 21, 2012 2:20 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| whydieanut wrote: |
Messages that have gone to the Catch terminal and purposely thrown would have BO Count > 0, while messages sent directly to the Failure terminal would have BO = 0
Someone please correct me if I am wrong... |
You are not wrong. But you cannot rely on this, because messages with nonzero backout count can be propagated to catch as well - if the input queue has nonzero backout treshold.
Last edited by Esa on Tue Feb 21, 2012 3:59 am; edited 1 time in total |
|
| Back to top |
|
|
| whydieanut |
| Posted: Tue Feb 21, 2012 3:09 am Post subject: |
|
|
Disciple
Joined: 02 Apr 2010
Posts: 186
|
Yes indeed! Thanks for pointing it out...
If going with this approach there are a few caveats...
BO Threshold in this case is very much a part of the overall design... |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 21, 2012 5:47 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| whydieanut wrote: |
| BO Threshold in this case is very much a part of the overall design... |
Also impiles all input to the flows is WMQ based. A failing flow could be exposed as a web service.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| whydieanut |
| Posted: Tue Feb 21, 2012 6:48 am Post subject: |
|
|
Disciple
Joined: 02 Apr 2010
Posts: 186
|
|
| Back to top |
|
|
|
|
