I have implemented your first choice. In my reading of the spec it is
perfectly OK, even expected, to extend the fault code mechanism. I think you
want to make sure to follow the spec about using SERVER and CLIENT. You are
right that a fault listener is what you need to get this done.
Rick Hansen
> -----Original Message-----
> From: Abrahamsson Mattias
> [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 26, 2001 8:38 AM
> To: '[EMAIL PROTECTED]'
> Subject: 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
>
