Faults

The exception handling mechanism in JAX-WS is complex. The Exception class has no default constructor with no parameters, and it is not Serializable to XML, making it unusable for an XML datatype. JAX-WS maps each exception to two different classes, one with the serial attributes and the other with the Exception referencing the WebFault. By default the Java Exception class is not serializable, has no default empty constructor, so it must be wrapped in another class which can be serialized to XML.

Probably the best blog reference on the subject is by Eben Hewett, although he calls the Java Exception 'Fault' and the serializable XML Fault 'Exception'. http://io.typepad.com/eben_hewitt_on_java/tech_notes/ Without customizations, JAX-WS insists on putting the Exception in the same namespace (package) as the service itself. It also results in classes called Exception_Exception, one of which is Serializable and the other which extends Exception.

In general we recommend using very few if any declared exceptions, in favor of undeclared runtime exceptions. Declared exceptions should only be used for business rule exceptions where the client is expected to do something different than normal error processing. Never for logic flow control, and never to simply pass an error message back to a client.

Model business exceptions as <<ApplicationException>><<WebFault>>, named {Class}Exception, thrown by the service method. Additional attributes and associations can be added to the Exception class. Association classes must be <<ValueObject>>. If exceptions are labeled <<ApplicationException>><<WebFault>> but not thrown by any service method, or if and Exception class thrown by a service method is not labeled as <<ApplicationException>><<WebFault>>, there will be a mismatch between the andromda and CXF generated code and the build will fail.

Next

Next up is the Custom Headers section.