File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Web Services and the fly likes RunTime Exception Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Web Services
Bookmark "RunTime Exception" Watch "RunTime Exception" New topic
Author

RunTime Exception

sudha swami
Ranch Hand

Joined: Apr 24, 2007
Posts: 179
Hi,
I would like to know how can i handle Runtime Exception in Webservice?
Thanks
Sudha
Ivan Krizsan
Ranch Hand

Joined: Oct 04, 2006
Posts: 2198
    
    1
Hi!
According to JAX-WS specification, if a runtime exception is thrown by a web service endpoint implementation and the message exchange pattern warrants a response, then a SOAP fault will be generated and, eventually, it will result in a javax.xml.ws.ProtocolException, or a subclass thereof, on the client side. Actually, if you are doing SOAP, the exception will be a javax.xml.ws.soap.SOAPFaultException exception.
If you want to do something on the server side when an exception occurs, there are two options, as far as I know:
1) Use Java exception handling and catch runtime exceptions originating from the processing layer of the web service in the interaction layer and do what you have to do.
2) Use a handler and do what you have to do in the handleFault method.
Note that handleFault will be invoked for all faults, both those originating from service-specific exceptions and those originating from system exceptions (in which runtime exceptions are included).

Best wishes!
Chintan Rajyaguru
Ranch Hand

Joined: Aug 19, 2001
Posts: 341
I agree with Ivan. However, from the design perspective, I would like to ask you this: Do you want to handle runtime exception on the service side or the client side?

RuntimeException means an exception that you aren't aware of at the design time e.g. NullPointerException. You should not handle any specific runtime exception on the client side. Ideally, the client should only handle the faults that are explicitly defined in the WSDL. For an explicitly defined fault, appropriate Java code will be generated on the client side so that you can handle the fault. If you have a requirement to handle other faults, use ideas suggested by Ivan. Ivan's suggestions can also be used to handle explicit faults (those defined in the WSDL).

If you are talking about the service side, ask yourself, why do you want to handle a runtime exception? Is that because you don't want to send any unknown exception in the SOAP response? If yes, you should design a fault mechanism with some kind of code. On the service side, you should catch Exception, set appropriate code and throw the exception so it gets converted into a fault defined in the WSDL.

Morale of the story is, stick to the faults defined in WSDL. Use fewer faults because in web services world, the client and the service are quite disconnected so you don't want your clients to have to know about bunch of faults. And finally, agree on a fault code/message mechanism to indicate different error responses (similar to what a browser does: response code 200 for OK, 404 for not found, 500 for server error etc.)


ChintanRajyaguru.com
SOADevelopment.com - Coming soon!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: RunTime Exception