axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anne Thomas Manes" <a...@manes.net>
Subject Re: exception handling strategies
Date Mon, 28 Jul 2003 22:09:51 GMT
Per the SOAP spec [1], the faultstring is not intended to convey a stack
trace:

> The faultstring element is intended to provide a human readable
explanation
> of the fault and is not intended for algorithmic processing. The
faultstring
> element is similar to the 'Reason-Phrase' defined by HTTP (see [5],
section 6.1).
> It MUST be present in a SOAP Fault element and SHOULD provide at least
> some information explaining the nature of the fault.

Instead it should convey something like "user exception" or "record not
found" or "database timeout". Detailed information about the exception
should be conveyed in the detail element:

> The detail element is intended for carrying application specific error
information
> related to the Body element. It MUST be present if the contents of the
Body
> element could not be successfully processed. It MUST NOT be used to carry
> information about error information belonging to header entries. Detailed
error
> information belonging to header entries MUST be carried within header
entries.

The detail message structure should be defined in the <types> section and
refer to it from a message <part>.

[1] http://www.w3.org/TR/SOAP/#_Toc478383507

Anne

----- Original Message -----
From: "chaddad" <chaddad@cobia.net>
To: <axis-user@ws.apache.org>
Sent: Monday, July 28, 2003 5:51 PM
Subject: RE: exception handling strategies


> Paul -  the xml-axis\test directory is a great place to start to view code
samples.  for example,
>
> /test/faults/TestEncode.java
> /test/soap12/TestFault.java
>
> 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.
>
> /Chris
>
>
> ---------- Original Message ----------------------------------
> From: Paul Mackles <paul.mackles@cnet.com>
> Reply-To: axis-user@ws.apache.org
> 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>
> >   ****BIG'OL STACK TRACE DELETED****
> >   </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 ca!
>  tch!
> > 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 [mailto:anne@manes.net]
> >> Sent: Sunday, July 27, 2003 2:27 PM
> >> To: axis-user@ws.apache.org
> >> 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" <paul.mackles@cnet.com>
> >> To: <axis-user@ws.apache.org>
> >> 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
> >> >
> >>
> >
>


Mime
View raw message