You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "James Grahn (Created) (JIRA)" <ji...@apache.org> on 2012/02/14 18:57:59 UTC
[jira] [Created] (AXIS2-5245) Information from RuntimeExceptions
escapes Axis2 error handling mechanism
Information from RuntimeExceptions escapes Axis2 error handling mechanism
-------------------------------------------------------------------------
Key: AXIS2-5245
URL: https://issues.apache.org/jira/browse/AXIS2-5245
Project: Axis2
Issue Type: Bug
Components: kernel
Affects Versions: 1.5.2
Reporter: James Grahn
RuntimeExceptions result in abnormal behavior from Axis2.
When an AxisFault is thrown, generally the fault is recorded in the message context, then a FaultFlow is invoked. Handlers operating in the FaultFlow context may then discover the fault through examination of the message contexts attached to its operation context.
If a runtime exception is thrown, however, the exception is lost, even though the FaultFlow is properly invoked. FaultFlow Handlers can no longer discover the exception which caused their invocation.
I recognize that best practice would include packaging every thrown exception in an AxisFault or AxisFault derivative. However, given that Axis2 does attempt to respond sensibly to RuntimeExceptions, I do not believe that having a "silent" FaultFlow invocation with no access to the originating exception is proper behavior.
The fix for this issue would involve (minimally) adding a catch clause to various methods in AxisEngine to set the failure reason on the message context when a runtime exception is intercepted, then rethrowing the original exception. Fault handlers would then be able to recover information from the originating exception.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
[jira] [Updated] (AXIS2-5245) Information from RuntimeExceptions
escapes Axis2 error handling mechanism
Posted by "James Grahn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-5245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
James Grahn updated AXIS2-5245:
-------------------------------
Attachment: Issue5245-AxisEngine.java.patch
Proposed minimally invasive fix. Failure reason will be attached to a message context even in failures resulting from a RuntimeException.
> Information from RuntimeExceptions escapes Axis2 error handling mechanism
> -------------------------------------------------------------------------
>
> Key: AXIS2-5245
> URL: https://issues.apache.org/jira/browse/AXIS2-5245
> Project: Axis2
> Issue Type: Bug
> Components: kernel
> Affects Versions: 1.5.4
> Reporter: James Grahn
> Labels: exception-handling
> Attachments: Issue5245-AxisEngine.java.patch
>
>
> RuntimeExceptions result in abnormal behavior from Axis2.
> When an AxisFault is thrown, generally the fault is recorded in the message context, then a FaultFlow is invoked. Handlers operating in the FaultFlow context may then discover the fault through examination of the message contexts attached to its operation context.
> If a runtime exception is thrown, however, the exception is lost, even though the FaultFlow is properly invoked. FaultFlow Handlers can no longer discover the exception which caused their invocation.
> I recognize that best practice would include packaging every thrown exception in an AxisFault or AxisFault derivative. However, given that Axis2 does attempt to respond sensibly to RuntimeExceptions, I do not believe that having a "silent" FaultFlow invocation with no access to the originating exception is proper behavior.
> The fix for this issue would involve (minimally) adding a catch clause to various methods in AxisEngine to set the failure reason on the message context when a runtime exception is intercepted, then rethrowing the original exception. Fault handlers would then be able to recover information from the originating exception.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
[jira] [Updated] (AXIS2-5245) Information from RuntimeExceptions
escapes Axis2 error handling mechanism
Posted by "James Grahn (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-5245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
James Grahn updated AXIS2-5245:
-------------------------------
Affects Version/s: (was: 1.5.2)
1.5.4
> Information from RuntimeExceptions escapes Axis2 error handling mechanism
> -------------------------------------------------------------------------
>
> Key: AXIS2-5245
> URL: https://issues.apache.org/jira/browse/AXIS2-5245
> Project: Axis2
> Issue Type: Bug
> Components: kernel
> Affects Versions: 1.5.4
> Reporter: James Grahn
> Labels: exception-handling
>
> RuntimeExceptions result in abnormal behavior from Axis2.
> When an AxisFault is thrown, generally the fault is recorded in the message context, then a FaultFlow is invoked. Handlers operating in the FaultFlow context may then discover the fault through examination of the message contexts attached to its operation context.
> If a runtime exception is thrown, however, the exception is lost, even though the FaultFlow is properly invoked. FaultFlow Handlers can no longer discover the exception which caused their invocation.
> I recognize that best practice would include packaging every thrown exception in an AxisFault or AxisFault derivative. However, given that Axis2 does attempt to respond sensibly to RuntimeExceptions, I do not believe that having a "silent" FaultFlow invocation with no access to the originating exception is proper behavior.
> The fix for this issue would involve (minimally) adding a catch clause to various methods in AxisEngine to set the failure reason on the message context when a runtime exception is intercepted, then rethrowing the original exception. Fault handlers would then be able to recover information from the originating exception.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org