The SOAP spec defines four fault codes: - Client (the fault was caused by the client - invalid message structure or invalid data). This exception would be appropriate for a "record not found" error or something like that. - Server (the fault was caused by the server). This exception would be appropriate for an app server or database error. - VersionMismatch (the client didn't send a SOAP 1.1 envelope) - MustUnderstand (a SOAP node didn't understand a Header block that specified mustUnderstand="1")
If a client receives a Client exception, it knows that there was something wrong with the message it sent, and it knows that it needs to change it's input message. If a client receive a Server exception, it should assume that the message it sent was okay, and it should try to resend the message. You can augment these four basic codes with subcodes, (e.g., Server.userException) but keep in mind that the WS-I Basic Profile says that you shouldn't. It's better form to put the additional information (userException) in the faultString element rather than in the faultCode element. And the detailed fault information should be returned in the <detail> element. To support non-Java clients, you should define fault detail messages in your WSDL for each of your custom exceptions. Unfortunately, when it comes to code, you have to use Axis-specific code in your server, and the client will need to use code specific to its SOAP runtime to catch and process the custom exceptions. Anne ----- Original Message ----- From: "Paul Mackles" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, July 27, 2003 1:26 PM Subject: exception handling strategies > Hi, > > I've seen a few threads on exception handling but nothing really concrete... The code I am attempting to wrap with a web service throws custom exceptions. Right now, I am just passing those exceptions onto AXIS and everything seems to be working well enough (i.e. a fault message is sent back to the client where the faultCode is 'Server.userException' and the faultString is the exception's message). However, lacking any real-world experience with WS/SOAP/etc, I'm concerned that these faults aren't going to be all that useful to non-java clients (unless all they do is exit or log a message when any faults occur). What I am wondering is if I want to be a little more specific with the faultCode/faultString, should I be catching these app-specific exceptions and wrapping them in an AXISFault exception? Is there something else I should be doing which perhaps doesn't require me to bring in AXIS-specific code? Ideally, I would be able to return something useful to non-java clients w! > hi! > le at the same time giving java clients everything they need to deserialize the exception so that it can be used just like an exception that was generated locally. Is this even possible? If so, can somebody give me some pointers? Thanks much. > > -- > Paul >
