axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "chaddad" <>
Subject RE: exception handling strategies
Date Mon, 28 Jul 2003 21:51:20 GMT
Paul -  the xml-axis\test directory is a great place to start to view code samples.  for example,


Axis is fully configurable as to the fault information and can conform to the WS-I suggestion.
  it does not conform out of the box because Java developers have been asking to embed exception
information in the message by default.  they also like the infamous stack trace, but IMHO
the inclusion of that info should be configurable.

yes, if you desire to modify the default behavior, you should catch the exception and re-throw
your customized AxisFault exception.


---------- Original Message ----------------------------------
From: Paul Mackles <>
Date:  Sun, 27 Jul 2003 12:34:22 -0700

>Thanks. I guess I'm still looking for some code samples or something that can show me
all of this in a more concrete fashion (even if it is specific to Axis). If I rely on axis's
default behvaior and just pass my app-specific exception up to axis, the fault message that
gets sent back to the client looks something like:
>  <soapenv:Fault>
>   <faultcode>soapenv:Server.userException</faultcode>
>   <faultstring>
>   </faultstring>
>  </soapenv:Fault>
>If I understand what you are saying correctly, it looks like axis is not necessarily heeding
the WS-I Basic Profile's suggestion not to augment the standard faultcodes. What's more, for
many of the exceptions that I am handling, I really need to set the faultCode to 'Client'
as the problem is indeed with the data contained in the message. Also, I'd rather not put
the stack trace in the faultString as there is much a client can do with it. You mentioned
something about defining the fault detail message for each of the custom exceptions in the
wsdl but I'm not clear on how to do that. The WSDL that axis generates does make reference
to the exception in the portType defintion but I'm not sure if that is what you are referring
to. Is there an example of some kind you can point me to? Also, I'm still not clear on how
I should be overriding the faultcode and faultstring values as I can't seem to find any sample
code for that either and the only thing I could come up with is to catch!
> my app-specific exceptions and wrap them with an AxisFault exception and pass the AxisFault
exception onto axis. Is that the suggested method?
>> -----Original Message-----
>> From: Anne Thomas Manes []
>> Sent: Sunday, July 27, 2003 2:27 PM
>> To:
>> Subject: Re: exception handling strategies
>> 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" <>
>> To: <>
>> 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
>> >

View raw message