wood burning stoves 2.0*
The moose likes Web Services and the fly likes Exception Handling Best Practice Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Web Services
Bookmark "Exception Handling Best Practice" Watch "Exception Handling Best Practice" New topic
Author

Exception Handling Best Practice

R van Vliet
Ranch Hand

Joined: Nov 10, 2007
Posts: 144
Hi guys,

I'm looking into changing the exception handling strategy used by our web services. Currently they expose exceptions that we think the client can realistically use as normal java exceptions. However, some SOAP client platforms such as .NET do not properly deal with this (for example, the .NET SOAP client doesn't allow more than one detail message in the fault element, making it impossible to pass stracktraces).

Now, is there a best practice when it comes to communicating faults from web services? I've read in a couple of places it's better to write small domain objects that can hold the return data as well as optional fault information. This seems a bit like bypassing the fault issues altogether which seems less than desirable. Note that an important requirement is compatibility with .NET's faulty SOAP implementation.

Thanks
R van Vliet
Ranch Hand

Joined: Nov 10, 2007
Posts: 144
Nobody any ideas on this? I'm still struggling with it.

Another issue is how to do web service versioning nicely (i.e. if you have an updated web service with changed calls, do you put the version number in the web service name or the namespace, etc.).

Remon
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Exception Handling Best Practice
 
Similar Threads
RunTime Exception
Exception handling!
Differentiate server down and no data found
Can we raise SOAP Fault for Application errors?
how to handle exception propagation in webservice client?