Re: Exception handling strategy question

[remko de knikker]

Situation:
OK, so far this helped, and pointed out the right direction in which to go. I had seen the SOAP Faults and understand now when to use them.
I use the document/literal or message style of web services in axis, since I am sending XML only.
I use the
'public Document method(Document doc)'
signature, and I need to be language neutral, and therefor have to return a Document regardless. The Java Exceptions are indeed caught by the client, but I can't use this method.
I managed to add a Fault to the SOAPBody object from the MessageContext and set its parameters, but as mentioned I need to return the Document, eg responseDoc, so the/any client can query this for Faults.... or do I have to deal with it differently??

Question:
How do I append the Fault object to the Document to be returned??






Anne Thomas Manes wrote:

There are four defined reasons to return a SOAP fault [1]:
- VersionMismatch: the request didn't specify the correct SOAP namespace
- MustUnderstand: a SOAP node did not understand a SOAP header that said
mustUnderstand='1'
- Client: the request failed either because it was malformed or contained
invalid data
- Server: the request failed because of some type of server error

Remko's example requires an error code of Client. The error report should be
returned in the fault <details> element. As long as you have Java on both
sides of the wire, the SOAP system on the client should be able to simply
rethrow the original exception (assuming that it has the exception class
installed). But if you intend to support non-Java clients, you should map
your various exceptions to specific SOAP fault messages.

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

Regards,
Anne

----- Original Message -----
From: "George Jagodzinski" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 24, 2003 3:22 PM
Subject: RE: Exception handling strategy question


  

if you are refering to business logic that happens after the request has
been accepted I would say that the best way is to return some type of
    

error
  

report. I could be wrong but it seems like soap fault should only be
    

thrown
  

if there was a conformance issue. Someone please correct me if I am wrong.

--George

-----Original Message-----
From: remko de knikker [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 24, 2003 3:22 PM
To: [EMAIL PROTECTED]
Subject: Exception handling strategy question


when implementing a web service and a ws client, what is the general
design principle for exception handling, when
1. when user entered a non-valid input value, for instance it doesn't
exist in the database?
Do I simply through a SOAPFault or is it better to append my own
<doesnotexist> tag?

2. as a client, do I catch an xxxxException/Fault, do I look for the
soapenv:Fault tag or do I have to look the webservice specific <wserror>
tag??

What is the best design strategy here??

thanks,
r