A bit confused by exceptions

[Fred Dushin <fr...@dushin.net>]

Looking at the JAX-WS 2.0 spec:

{{{
The following standard exceptions are defined by JAX-WS.

''javax.xml.ws.WebServiceException'' A runtime exception that is  
thrown by methods in JAX-WS APIs when errors occur during local  
processing.

''javax.xml.ws.ProtocolException'' A base class for exceptions  
related to a specific protocol binding.  Subclasses are used to  
communicate protocol level fault information to clients and may be  
used by a service implementation to control the protocol specific  
fault representation.

''javax.xml.ws.soap.SOAPFaultException'' A subclass of  
ProtocolException, may be used to carry SOAP specific information.

''javax.xml.ws.http.HTTPException'' A subclass of ProtocolException,  
may be used to carry HTTP specific information.
}}}

Are these recommended exception types, when writing CXF applications?

The reason I ask is this.  My interceptors are designed to raise  
org.apache.cxf.interceptor.Fault exteptions under error conditions,  
as this seems to be the prescribed behavior.  Why do I think this?   
Not sure.  I think I read it somewhere.  (Sorry I can't be more  
specific).  These exceptions are being thrown from server-side  
interceptors.

What I'm finding is, my client is getting exceptions of type  
org.apache.cxf.binding.soap.SoapFault.  Tracing the inheritance tree,  
we basically seem to have:

  + java.lang.RuntimeException
  |
  + org.apache.cxf.common.i18n.UncheckedException
  |
  + org.apache.cxf.interceptor.Fault
  |
  + org.apache.cxf.binding.soap.SoapFault

No javax.ws.xml.* to be found.  Am I throwing the wrong types from my  
interceptors?  Is there any guidance for what to do here?  (Apologies  
for the naivete of the question)

As an aside, is there an analogue to CORBA::SystemException and  
CORBA::UserException (and their descendents) in jax-ws?  The somewhat  
nice thing about exceptions of that type is that it is a catch-all  
for problems with the plumbing, as opposed to problems with the  
application, which can form a convenient switch in a lot of code.

PS>  It's a shame exceptions aren't interfaces in Java.  (It's also a  
shame Java doesn't support multiple inheritance, but I won't ignite  
another holy war! :)

-Fred

RE: A bit confused by exceptions

["Glynn, Eoghan" <eo...@iona.com>]

Fred,

Remember CXF supports pluggable frontends, and thus interceptors should
in general be independent of the frontend that the user happens to
choose ... i.e. your interceptors should work just as well regardless of
whether JAX-WS or the simple frontend or whatever is being used at the
application level. 

So the short answer is that throwing the javax.xml.ws.* exceptions from
an arbitrary interceptor is probably not a great idea. Someone writing a
simple-frontend-based app is likely to be unpleasantly surprised if
their inovcation barfs back a javax.xml.ws.ProtocolException for
example. 

The exceptional case is of course when the interceptor is known only
ever to be used if JAX-WS is in play. And we do have a bunch of those
(for example the interceptors that wrap the JAX-WS Handler chains). 

I don't think there really is a direct analogue for
CORBA::SystemExceptions in CXF, in the sense that interceptors are free
to throw any unchecked exception type. 

Similarly I don't think there's really an equivalent of
CORBA::UserException. Depends again on the frontend, but for JAX-WS at
least, a <wsdl:fault> simply maps onto a direct subclass of Exception
... i.e. there's no common base class for all exception types generated
from WSDL faults. 

But maybe we do need to clearly call out any non-binding conventions we
expect interceptor impls to follow wrt to exception types. For example
the throwing of org.apache.cxf.interceptor.Fault that you mention. 

Whether we'd go further and harden the convention by making Fault a
checked exception, so that putting it in the signature of
Interceptor.handleMessage() actually means something, and then treat any
unchecked exception thrown from Interceptor.handleMessage() as a "nasty
surprise" as opposed to an contingency envisaged by the design ... well,
that's a question on which no doubt there would be robust discussion.

But its late and I've had my fill of Java coding-style jihad for one day
:)

Cheers,
Eoghan
 

> -----Original Message-----
> From: Fred Dushin [mailto:fred@dushin.net] 
> Sent: 04 April 2007 20:24
> To: cxf-user@incubator.apache.org
> Subject: A bit confused by exceptions
> 
> Looking at the JAX-WS 2.0 spec:
> 
> {{{
> The following standard exceptions are defined by JAX-WS.
> 
> ''javax.xml.ws.WebServiceException'' A runtime exception that 
> is thrown by methods in JAX-WS APIs when errors occur during 
> local processing.
> 
> ''javax.xml.ws.ProtocolException'' A base class for 
> exceptions related to a specific protocol binding.  
> Subclasses are used to communicate protocol level fault 
> information to clients and may be used by a service 
> implementation to control the protocol specific fault representation.
> 
> ''javax.xml.ws.soap.SOAPFaultException'' A subclass of 
> ProtocolException, may be used to carry SOAP specific information.
> 
> ''javax.xml.ws.http.HTTPException'' A subclass of 
> ProtocolException, may be used to carry HTTP specific information.
> }}}
> 
> Are these recommended exception types, when writing CXF applications?
> 
> The reason I ask is this.  My interceptors are designed to 
> raise org.apache.cxf.interceptor.Fault exteptions under error 
> conditions,  
> as this seems to be the prescribed behavior.  Why do I think this?   
> Not sure.  I think I read it somewhere.  (Sorry I can't be 
> more specific).  These exceptions are being thrown from 
> server-side interceptors.
> 
> What I'm finding is, my client is getting exceptions of type 
> org.apache.cxf.binding.soap.SoapFault.  Tracing the 
> inheritance tree, we basically seem to have:
> 
>   + java.lang.RuntimeException
>   |
>   + org.apache.cxf.common.i18n.UncheckedException
>   |
>   + org.apache.cxf.interceptor.Fault
>   |
>   + org.apache.cxf.binding.soap.SoapFault
> 
> No javax.ws.xml.* to be found.  Am I throwing the wrong types 
> from my interceptors?  Is there any guidance for what to do 
> here?  (Apologies for the naivete of the question)
> 
> As an aside, is there an analogue to CORBA::SystemException 
> and CORBA::UserException (and their descendents) in jax-ws?  
> The somewhat nice thing about exceptions of that type is that 
> it is a catch-all for problems with the plumbing, as opposed 
> to problems with the application, which can form a convenient 
> switch in a lot of code.
> 
> PS>  It's a shame exceptions aren't interfaces in Java.  (It's also a
> shame Java doesn't support multiple inheritance, but I won't 
> ignite another holy war! :)
> 
> -Fred
>