You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-user@ws.apache.org by Abrahamsson Mattias <ma...@consultant.volvo.com> on 2001/06/26 15:38:02 UTC

How to handle faults?

Hi all,

I have a problem where I need some guidance before developing a solution.

The problem:
------------

Our application needs to be able to return application errors in a way that makes it possible for a client to programmatically identify the error. The client should be able to take proper action and inform a user on various error events. Errors can include diverse things such as problems with a database and erroneous arguments (e.g. validation errors) and more. We would like to provide a mapping for each unique error condition and return this error in an encoded format possible for a client to interpret and translate to specific exception handling routines for the client platform.

Possible solutions:
-------------------

1. Encode the application error using the faultcode. I am a little uncertain if this is allowed according to the specification. An example of encoded error information could be "SOAP-ENV:Server.Application.DatabaseError", "SOAP-ENV:Server.Application.ValidationError" or something similar (am I allowed to "extend" the SOAP-ENV:Server with point notation?!). More specific information needed to describe an error could be embedded in the faultdetails (faultdetails in this case are not used to identify the type of error but to get more detailed information like stack traces for bug reports and similar).

2. Use the faultdetails for complete descriptions of errors in the application. Specific information can be embedded in the faultdetails thus describing the error condition. This is similar to the first approach but is not as straightforward for the client, at least I think so.

3. Somehow parse the faultstring. I don't like this solution since the faultstring according to the specification should be in a "human readable" format thus not being a good candidate for program logic.

4. Any other alternative which I have not thought of.

I would prefer a solution based on the first alternative in one form or another. Is this a good way to do it and is it allowed according to the specifications? If I interpret everything correctly I would have to build a fault listener to fill in faultdetails for an application error and a custom provider to intercept and change the fault code of a thrown SOAPException as it will otherwise default to "SOAP-ENV:Server".

Thanks for you time and any input you might want to contribute.

/Mattias