RE: AxisFault

[Glen Daniels <gd...@macromedia.com>]

Hi Richard!

Here's my take.

1) Faults across the wire should use the <faultcode> element to indicate what went wrong, and the <details> element to contain specific data about the fault.  In other words, faultcode should map to a particular exception.

2) Any fault inside Axis which may need to be sent across the wire should inherit from AxisFault, and should handle setting the faultcode appropriately.  For instance, instead of throwing an AxisFault in SimpleAuthorizationHandler, we should have an AuthorizationFault which extends AxisFault and automatically sets up faultcode/faultstring.  This would enable us to catch particular exceptions internally, and also send them across the wire.

3) Any purely internal Axis fault which won't need to be sent across the wire does not need to (and probably shouldn't) inherit from AxisFault.

So, stuff I'd like to see:

* More subclasses of AxisFault for particular exceptions which may get propagated to the client, and some kind of mapping between faultcodes<->Exception types

* Research into not using AxisFault to handle truly internal Axis problems, with individual components deciding whether to catch/wrap such exceptions for sending on the wire

* Per the conversation we had yesterday re: "system" vs. "user" exceptions in Handlers, I'd still prefer that Handler writers throw SOAP faults (i.e. AxisFaults) when appropriate, and consider other types of Exceptions as internal failures.  Then we can provide options for a particular engine/service/handler which indicate whether or not we'd like such internal Exceptions to be wrapped and tossed back as AxisFaults.

--Glen

> -----Original Message-----
> From: Richard Sitze [mailto:rsitze@us.ibm.com]
> Sent: Tuesday, April 30, 2002 12:05 PM
> To: axis-dev@xml.apache.org
> Subject: AxisFault
> 
> 
> I'd like to improve the error handling within Axis.  So, I'm 
> soliciting
> views on the proper use/place of AxisFault.
> 
> It appears to have multiple uses, with some grey areas:
> 
> 1.  Delivers Business Exceptions (handlers, web services 
> targets [EJBs,
> JavaBeans, etc]) to client code
> 2.  Delivers many internal exceptions to client code.
> 
> I plan on scrubbing and changing the exceptions, as per 
> guidelines (open
> for comment) added this morning to the developers guide.
> 
> Community Comments?
> 
> <ras>
> 
> *******************************************
> Richard A. Sitze            rsitze@us.ibm.com
> CORBA Interoperability & WebServices
> IBM WebSphere Development
> 

Re: AxisFault

[Harald Schmitt <co...@hschmitt.de>]

Hi all,
1) I think it is important to hold this flexibel in regard to determine
the right filling for <faultcode> and so on. You could imagine that the
same fault needs other <faultcode> and so on for SOAP 1.1 or SOAP 1.2 or
...
Harald 

Glen Daniels schrieb:
> 
> Hi Richard!
> 
> Here's my take.
> 
> 1) Faults across the wire should use the <faultcode> element to indicate what went wrong, and the <details> element to contain specific data about the fault.  In other words, faultcode should map to a particular exception.
> 
> 2) Any fault inside Axis which may need to be sent across the wire should inherit from AxisFault, and should handle setting the faultcode appropriately.  For instance, instead of throwing an AxisFault in SimpleAuthorizationHandler, we should have an AuthorizationFault which extends AxisFault and automatically sets up faultcode/faultstring.  This would enable us to catch particular exceptions internally, and also send them across the wire.
> 
> 3) Any purely internal Axis fault which won't need to be sent across the wire does not need to (and probably shouldn't) inherit from AxisFault.
> 
> So, stuff I'd like to see:
> 
> * More subclasses of AxisFault for particular exceptions which may get propagated to the client, and some kind of mapping between faultcodes<->Exception types
> 
> * Research into not using AxisFault to handle truly internal Axis problems, with individual components deciding whether to catch/wrap such exceptions for sending on the wire
> 
> * Per the conversation we had yesterday re: "system" vs. "user" exceptions in Handlers, I'd still prefer that Handler writers throw SOAP faults (i.e. AxisFaults) when appropriate, and consider other types of Exceptions as internal failures.  Then we can provide options for a particular engine/service/handler which indicate whether or not we'd like such internal Exceptions to be wrapped and tossed back as AxisFaults.
> 
> --Glen
> 
> > -----Original Message-----
> > From: Richard Sitze [mailto:rsitze@us.ibm.com]
> > Sent: Tuesday, April 30, 2002 12:05 PM
> > To: axis-dev@xml.apache.org
> > Subject: AxisFault
> >
> >
> > I'd like to improve the error handling within Axis.  So, I'm
> > soliciting
> > views on the proper use/place of AxisFault.
> >
> > It appears to have multiple uses, with some grey areas:
> >
> > 1.  Delivers Business Exceptions (handlers, web services
> > targets [EJBs,
> > JavaBeans, etc]) to client code
> > 2.  Delivers many internal exceptions to client code.
> >
> > I plan on scrubbing and changing the exceptions, as per
> > guidelines (open
> > for comment) added this morning to the developers guide.
> >
> > Community Comments?
> >
> > <ras>
> >
> > *******************************************
> > Richard A. Sitze            rsitze@us.ibm.com
> > CORBA Interoperability & WebServices
> > IBM WebSphere Development
> >