| Author |
Message
|
| sanjoo |
 Posted: Thu Feb 28, 2013 4:12 am Post subject: "throw" exception not getting caught |
 |
|
Acolyte
Joined: 26 Oct 2005
Posts: 65
|
Hi,
I have following scenario-
Out terminal of FileInput node -->compute node1 --> (Sub Flow1) --> sub flow1 failure terminal --> throw user exception
Catch terminal of file input node --> exception handler subflow2 --> throw node
Whenver any exception happens in sub flow1, it is supposed to throw exception and go to catch terminal, perform exception handling and again throw an exception so as to roll back file in mqsibackout folder. This is not happening. It is just ending on throw statement and not going back to catch terminal.
Further if somehow I created exception in compute node1, it goes to catch terminal, does the exception handling but somehow does not throw an exception and file is not moved to mqsibackout folder. We are losing the file.
We are on AIX5.3, WMB6.1.0.8 and MQ7.0
Appreciate any help.
_________________
Sanjoo
Keep smiling
 |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Thu Feb 28, 2013 5:49 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| sanjoo |
| Posted: Thu Feb 28, 2013 8:56 pm Post subject: |
|
|
Acolyte
Joined: 26 Oct 2005
Posts: 65
|
We dont use trace nodes. Will they be of any assistance here? We already have log4j enabled app logs which let us know whats heppening with message.
_________________
Sanjoo
Keep smiling
|
|
| Back to top |
|
|
| cociu_2012 |
| Posted: Fri Mar 01, 2013 12:12 am Post subject: Re: "throw" exception not getting caught |
|
|
Acolyte
Joined: 06 Jan 2012
Posts: 72
|
Have you tried to generate the user log? How is your flow ending? You should be albe to see the exact behavior in the log file.
Give us more details. There could be a problem with generating the user exception, or you are using cath/fail on other nodes, and the exception is not rolled back all the way to the file node. Again, the user trace will let you see the exact path of the flow. |
|
| Back to top |
|
|
| sanjoo |
| Posted: Fri Mar 01, 2013 1:09 am Post subject: |
|
|
Acolyte
Joined: 26 Oct 2005
Posts: 65
|
Thanks. Let me be more specific.
FileOutput node1 --> Out terminal --> Compute node1 --> MQ output node1 --> Failure terminal --> throw user exception
FileOutput node1 --> catch terminal --> exception handler
transaction mode of file output node1 is set to No
transaction mode of MQ output node1 is set to No
In above example if I somehow generate exception on MQ output node1, it goes to failure path and throws user exception and thread ends there. It does not fall back to catch terminal of file output node1.
Am I missing some basic thing here?
_________________
Sanjoo
Keep smiling
|
|
| Back to top |
|
|
| sanjoo |
| Posted: Fri Mar 01, 2013 1:11 am Post subject: |
|
|
Acolyte
Joined: 26 Oct 2005
Posts: 65
|
Just one correction.. read file input instead of file output in above example.
ie
FileInput node1 --> Out terminal --> Compute node1 --> MQ output node1 --> Failure terminal --> throw user exception
FileInput node1 --> catch terminal --> exception handler
transaction mode of file inpput node1 is set to No
transaction mode of MQ output node1 is set to No
In above example if I somehow generate exception on MQ output node1, it goes to failure path and throws user exception and thread ends there. It does not fall back to catch terminal of file input node1.
Am I missing some basic thing here?
_________________
Sanjoo
Keep smiling
|
|
| Back to top |
|
|
| cociu_2012 |
| Posted: Fri Mar 01, 2013 2:02 am Post subject: |
|
|
Acolyte
Joined: 06 Jan 2012
Posts: 72
|
| sanjoo wrote: |
FileInput node1 --> Out terminal --> Compute node1 --> MQ output node1 --> Failure terminal --> throw user exception
|
Why you've connected Failure terminal from MQ output node?
You are trying to get the user generated exception to go back even more?
I'm not sure that will work. It someone knows, please correct me.
What you can do is, to connect catch terminat of the MQ node, and then the failure terminal to your exception handler subflow. In this case, the user generated exception will be get caugth by the failure terminal. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Fri Mar 01, 2013 2:15 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| sanjoo wrote: |
FileInput node1 --> Out terminal --> Compute node1 --> MQ output node1 --> Failure terminal --> throw user exception
FileInput node1 --> catch terminal --> exception handler |
For the FileInput node, what are the settings for "Retry Mechanism" and "Action on failing file"?
| sanjoo wrote: |
| In above example if I somehow generate exception on MQ output node1, it goes to failure path and throws user exception and thread ends there. |
The documentation doesn't seem to be clear about what a non-Input node should do with an Exception thrown from its fail flow. Perhaps a usertrace could provide more details.
What happens to the MQOutput Exception if the MQOutput Failure terminal is disconnected? |
|
| Back to top |
|
|
| ah.khalafallah |
| Posted: Sun Mar 03, 2013 3:32 am Post subject: |
|
|
Newbie
Joined: 03 Mar 2013
Posts: 5
|
Hi Sanjoo,
I believe that i have a solution for you...
if you connect the FileInput node1--> Out Terminal to a TryCatch Node,
& then after that you may resume all your flow normally,
then in the TryCatch Node add the exception handling logic to the Catch Terminal
this would fire the exception that was triggered from the MQ Output Node through the "Throw User Exception" node to the first of the flow, where the TryCatch Exists...
you may give it a try...
_________________
Middleware Developer
Certified Websphere Message Broker v.7.0
Certified Websphere Transformation Extender v.8.2 |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Mar 03, 2013 5:28 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ah.khalafallah wrote: |
| I believe that i have a solution for you... |
I'd call it a workaround rather than a solution.
| ah.khalafallah wrote: |
if you connect the FileInput node1--> Out Terminal to a TryCatch Node,
& then after that you may resume all your flow normally,
then in the TryCatch Node add the exception handling logic to the Catch Terminal
this would fire the exception that was triggered from the MQ Output Node through the "Throw User Exception" node to the first of the flow, where the TryCatch Exists... |
I agree that if you don't use the terminals on the input node then you can cease to worry about how the terminals on the input node work.
It's hardly the best way forward.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sanjoo |
| Posted: Wed Mar 06, 2013 3:34 am Post subject: |
|
|
Acolyte
Joined: 26 Oct 2005
Posts: 65
|
Cracked the case...
Thanks a lot to everybody who shared their valuable inputs.
Actual scenario was -
FileInput node1 --> Out terminal --> JavaCompute node1 --> MQ output node1 --> Failure terminal --> throw user exception
And I was not able to throw exception back.
Apparently culprit was JavaComputeNode1 where in we have
Try{
---
some code here
---
getOutputTerminal("out").propagate(outAssembly);
catch (Exception z)
z.printStackTrace();
}
To my surprise, propagate method in JCN works just like propagate statement in esql. If any exception happens in further nodes for eg MQOutputNode1 in this case, it was getting caught in catch block of JCN. And since we were not handling there properly, thread was ending there and was not falling back to file input node's catch terminal.
Just removed catch block in JCN and flow is working like magic now.
However, I am still pondering is there any equivalent java method to esql's "RETURN TRUE" statement?
_________________
Sanjoo
Keep smiling
|
|
| Back to top |
|
|
| Esa |
| Posted: Wed Mar 06, 2013 4:13 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| sanjoo wrote: |
However, I am still pondering is there any equivalent java method to esql's "RETURN TRUE" statement? |
No, there is no such method. But java has return statement as well. It does not work the same way than RETURN TRUE in ESQL, of course, because in JCN there is no default propagation upon return. You must always propagate explicitely.
So java return actually equals RETURN FALSE. |
|
| Back to top |
|
|
| rvmson |
| Posted: Wed Mar 06, 2013 9:44 am Post subject: |
|
|
Newbie
Joined: 06 Mar 2013
Posts: 6
|
What I found that works for me is to add the following catch statement to the try/catch of the JCN.
catch (MbBrokerException e) {
throw e;
}
This appears to catch and re-throw all downstream exceptions thrown in the flow.
The position of this catch is obviously dependent on what other exceptions are being caught in the JCN. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Fri Mar 08, 2013 12:40 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| sanjoo wrote: |
Apparently culprit was JavaComputeNode1 where in we have
| Code: |
try {
...
getOutputTerminal("out").propagate(outAssembly);
catch (Exception z)
z.printStackTrace();
} |
|
It's a generally bad practice to catch a super-class Exception, where a sub-class Exception would do. And, as WMB is not purely Java, printStackTrace() is not likely to be useful for downstream Exceptions.
| sanjoo wrote: |
| However, I am still pondering is there any equivalent java method to esql's "RETURN TRUE" statement? |
Calling a method, and returning from a method are inverse operations, so there's not likely to be any sort of equivalence there. But the Java return statement is equivalent to the ESQL RETURN statement.
To clear up some confusion about Compute/Database/Filter nodes, it's not the RETURN statement that's responsible for deciding whether to propagate a message. The Compute/Database/Filter node calls its ESQL Main() function, with declared return type BOOLEAN, and the Main() function executes. If the Main function completes normally, then it returns a value to the calling node. But it's the node which then decides if or where to propagate the message, based on the return value, after the ESQL completes.
For a JavaCompute node, the evaluate() method has a declared return type void; it doesn't return a value. So the JavaCompute node itself doesn't decide whether to propagate a message after it's evaluate() method returns, in the same way that the other nodes would.
| Quote: |
What I found that works for me is to add the following catch statement to the try/catch of the JCN.
| Code: |
catch (MbBrokerException e) {
throw e;
} |
|
Why? What's the point of catching the exception, doing nothing with it, and then rethrowing it? How is that different from simply not adding the catch block, and not catching the exception? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Mar 08, 2013 2:24 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| rekarm01 wrote: |
Why? What's the point of catching the exception, doing nothing with it, and then rethrowing it? How is that different from simply not adding the catch block, and not catching the exception? |
I believe the point here is eclipse requiring you to either catch the exception or explicitly requiring a throws statement in the method signature... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
