Mailing-List: contact java-dev-help@axis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@axis.apache.org
Date: Wed, 30 Jan 2013 20:49:13 +0000 (UTC)
From: "James Grahn (JIRA)" <jira@apache.org>
To: java-dev@axis.apache.org
Message-ID: <JIRA.12542573.1329242200698.217679.1359578953454@arcas>
In-Reply-To: <JIRA.12542573.1329242200698@arcas>
References: <JIRA.12542573.1329242200698@arcas>
Subject: [jira] [Commented] (AXIS2-5245) Information from RuntimeExceptions
 escapes Axis2 error handling mechanism
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/AXIS2-5245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13566885#comment-13566885 ] 

James Grahn commented on AXIS2-5245:
------------------------------------

Actually came across this problem again recently in testing.  

A flaw in the test generated a RuntimeException within the tested services and I had no means to obtain the exception for my logs.
                
> 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