In the section 11.3 Web Services Interaction Results, I read the following
The following are possible ways of handling service-specific exceptions in client applications:
• Wrap the checked service-specific exceptions and throw an unchecked exception.
• Notify the user of the client application that an error has occurred.
• Do not allow service-specific exceptions propagate throughout the client application, but rather wrap them in exceptions specific to the client application.
This limits the impact of changes in the web service interface.
• Handle exceptions at one single place in the client application.
Prevents duplication of code and limits impact of changes in the web service interface.
Why do we need to convert service specific exceptions to run time exceptions, espicially when one of the artifacts being generated contains the servicespecific exception.
Say for example, if my service throws CustomException and on client side (java), one of the artifacts generated would be CustomException_Exception. I think handling CustomException_Exception would be easy and straight forward than handling some ArithmeticException (division by zero) or some other sort. How does this work in non-java client, when java webservice throws ArithmeticException, instead of custom exception.
The idea is that you have a client "layer", containing the generated artifacts and the code the uses the generated artifacts.
If you let service-specific exceptions "escape" this layer, then any changes in the service and the exceptions it "throws" will affect the client beyond the above mentioned "layer".
If you, in this layer, wrap or translate service specific exceptions to other, general, exceptions then any changes in the service and the exceptions it "throws" will not affect anything beyond the "layer" in the client.