File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
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
JavaRanch » Java Forums » Java » Web Services
Bookmark "Exception Handling Best Practice" Watch "Exception Handling Best Practice" New topic

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.

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.).

I agree. Here's the link:
subject: Exception Handling Best Practice
jQuery in Action, 3rd edition