Currently, Axis has a very simple mechanism for dealing with error conditions. The code (whether it is the Web service or some pluggable component such as a handler) can throw an exception, which will then be caught by the Axis engine and propagated back to the transport listener. The transport listener will then typically return it to the client (in the HTTP case)óbut that is an implementation choice. If the exception that is thrown is a Java exception, it will be converted into a specialized Axis class, AxisFault. This class is defined to contain all the information that would go into a SOAP fault response message. The faultcode is set to Server.generalException, and the detail part of the fault will contain the stack trace.
public AxisFault(String code, String str, String actor, Element details); public AxisFault(QFault code, String str, String actor, Element details);
Like the SOAP fault definition, AxisFaults contain faultcode, faultstring, faultactor, and faultdetails fields. The QFault class is a utility class that contains the fully qualified name of the fault code (namespace and local name). The faultdetails field is an array of DOM elements so that the specific XML that is contained in the fault can be tailored to any specific needs.
When Axis is completed, it is expected to include a more robust system for handling faults. In particular, some of the ideas being discussed include:
These ideas are not guaranteed to be implemented in the first release of Axis; they are just the current list of ideas being considered.