[ https://jira.jboss.org/jira/browse/JBPM-1954?page=com.atlassian.jira.plug... ] Alejandro Guizar reassigned JBPM-1954: -------------------------------------- Assignee: Alejandro Guizar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBPM-1954?page=com.atlassian.jira.plug... ] Jorge Soria commented on JBPM-1954: ----------------------------------- Hola Alejandro. In principle you are right. An exception should be thrown back to the infringer and this is sound whenever we do not have any exception-handler. However, if we have an exception-handler, it will try to execute correction code and then return. In our case, we have a custom exception-handler that makes the process end gracefully. And it does so without any problems, but when it returns from the call inline 148 raiseException(exception, executionContext); the Decision has swallowed up the exception and .... continues to the next node with transition = null. The result is then that the exception that should be thrown has disappeared and the client gets an unrelated exception that is indeed hard to relate to. What you sugest is to leave things as they are, because the raiseException() method already re-throws the exception if there is no exception-handler. What I sugest is to comply to the jBPM philosophy and, if the exception-handler has done its job, continue with the process as it is defined, or from the state the exception-handler has left it in. The problem with just re-throwing the exception or leaving the code as it is, is that the process no longer complies with the central statement in "JBoss jBPM - Workflow in Java. jBPM jPDL User Guide. 3.2.3" section 10.7: "The exception handling mechanism of jBPM only applies to java exceptions. Graph execution on itself cannot result in problems. It is only the execution of delegation classes that can lead to exceptions." and that the exception-handler is executed and so discarded, leaving the process in an unknown state. Saludos. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBPM-1954?page=com.atlassian.jira.plug... ] Work on JBPM-1954 started by Alejandro Guizar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBPM-1954?page=com.atlassian.jira.plug... ] Alejandro Guizar commented on JBPM-1954: ---------------------------------------- Que tal, Jorge. Your original comment did not explicitly state that the specific case you considered anomalous was the exception thrown by a delegation class being handled but not rethrown. My comment in no way meant that things should be left as they were, just that the proposed solution was, in my view, not immediately applicable and needed further discussion. Taking the additional input from your last comment I wrote a test case and observed the JbpmException you described. I agree that since the original exception was handled, the subsequent JbpmException is out of place. I still disagree on the proposed solution, tough. The decision node is not a state. Under no circumstances should the token stay there. After an exception is handled, no decision has been made on the transition to take. The existing Decision.execute code already contains the proviso below in case no transition was selected. if (transition == null) { transition = getDefaultLeavingTransition(); if (transition == null) throw new IllegalStateException("decision cannot select transition: " + this); } I believe the above is the most adequate way to resume execution after an exception is handled. Of course, if the exception handler has moved the token to a different node, then the execute() method should just return, as you propose. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira