SCT now handles exceptions thrown by execution listeners #344
Conversation
| this.applicationFailedEvent.getException()).getExitMessage()); | ||
| setMessages(invokeOnTaskEnd(this.taskExecution)); | ||
| if(this.listenerFailed) { | ||
| this.taskExecution.setExitCode(1); |
There was a problem hiding this comment.
Should this be hardcoded as 1, a specific value that we specify other than one (to indicate the specific error condition being an exception was thrown via a SCT listener), or should this be the result of any configured ExitCodeGenerator? Where in the lifecycle does the ExitCodeGenerator get called based on this logic?
There was a problem hiding this comment.
With this PR we stop processing all TaskExecutionListeners when an exception is thrown by a listener. So if I understand you correctly, you want to check to see if the exception thrown by the listener implements the ExitCodeGenerator interface and if so use that exit code.
There was a problem hiding this comment.
No. I wouldn't expect an exception to implement ExitCodeGenerator. However, there may be one in the ApplicationContext. I'm asking if we should use it...
| this.listenerFailed = true; | ||
| this.taskExecution.setErrorMessage(listenerException.getMessage()); | ||
| this.listenerException = listenerException; | ||
| throw listenerException; |
There was a problem hiding this comment.
Bad practice to use duplicate variable names. Please use something different.
|
This PR should also have some form of update of documentation associated with it. Both reference docs and java docs need to be updated to document the lifecycle change. |
|
Documentation updated as well. |
|
Rebased, squashed, and merged as 3f316a0 |
resolves #341