-
1. Re: Help required with exception handling on transitions
kukeltje Jul 3, 2006 9:21 AM (in response to scott_mathieson)In short you mean that an errorhandler works when an error happens on an action that was not on a transition.
Regarding the storage: then store it somewhere else. It's up to you.
Ronald -
2. Re: Help required with exception handling on transitions
scott_mathieson Jul 3, 2006 9:43 AM (in response to scott_mathieson)In short you mean that an errorhandler works when an error happens on an action that was not on a transition.
The exception handler always works, in that it always catches the exception and processes it. The problem is that if I set the node in the exception handler, this gets over-written by the transition e.g.
task.end() <- Exception in the action on the transition happens here and the
handler sets the node to the 'Error' node, but on completing the signalling of this node, the transition to the default node for this task happens.
Basically there is no way to tell the signal handler that it should not continue processing when its been dealt with by an exception handler.
Hope that made sense. ;-) -
3. Re: Help required with exception handling on transitions
koen.aers Jul 4, 2006 1:27 PM (in response to scott_mathieson)Scott,
It is generally not a good idea to try to propagate the graph execution from an action in an exception handler. Use the exception handler to set a process variable and then use a decision node after the task node to route the graph execution to the node you want based on the value of this process variable. Or write a customized version of the task node that incorporates this behaviour if you wish.
Regards,
Koen -
4. Re: Help required with exception handling on transitions
kukeltje Jul 4, 2006 5:27 PM (in response to scott_mathieson)hmmm... normally I would agree, but we have a kind of identical situation as well. The customer thinks he wants to put the process in a certain error state if something happens. If we model this in (from EVERY state) it gets kind of blurry. 50% of all icons in the process are decisions all going to this error state. The customer has the choice to correct something and then put the process back in the state it came from. If you've ever seen a web, it must have been based on this process diagram. So Manipuliating the tokens, just for this kind of error handling seems a good solution for us. Luckily we do not have the problems that errors on actions on transitions (mainly sending a mail or something like that) is not an issue for us.