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:[EMAIL PROTECTED]]
> Sent: Tuesday, April 30, 2002 12:05 PM
> To: [EMAIL PROTECTED]
> 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            [EMAIL PROTECTED]
> CORBA Interoperability & WebServices
> IBM WebSphere Development
> 

Reply via email to