cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <>
Subject RE: A bit confused by exceptions
Date Thu, 05 Apr 2007 01:20:58 GMT


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* 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 for

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


> -----Original Message-----
> From: Fred Dushin [] 
> Sent: 04 April 2007 20:24
> To:
> Subject: A bit confused by exceptions
> Looking at the JAX-WS 2.0 spec:
> {{{
> The following standard exceptions are defined by JAX-WS.
> '''' A runtime exception that 
> is thrown by methods in JAX-WS APIs when errors occur during 
> local processing.
> '''' 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.
> '''' A subclass of 
> ProtocolException, may be used to carry SOAP specific information.
> '''' 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* 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

View raw message