Thankyou for your inputs.
I was talking about checked exceptions. If not showing the actual message, atleast show that an exception occurred? Suppose, if there is a jdbc connection failure, I would catch that exception at the server side. But at the same time I want to pass a message to the client that an exception occured. If I dont do that, all the checked exceptions caught at the server side, are turned to Remote exceptions at the client side. And the developer writing the client code would see it as a remote exception no matter what kind of exception was caught at the server side.
If I am not very clear please refer to the below text.
"Exceptions could be thrown inside a Web Service for various reasons. The possible types of exceptions that could be thrown are RuntimeException, RemoteException, SOAPFaultException and User Defined Exception.
The Web Service developer might try throwing a RuntimeException such as NullPointerException or ArrayIndexOutOfBoundsException inside the Web Service. But, throwing RuntimeException inside the Web Service is considered to be a bad exercise because RuntimeException will always be converted into RemoteException at the client side. While the client is waiting to catch the RuntimeException after invoking a Web Service, he will get only the RemoteException instead of RuntimeException. Eventually, he cannot perform proper error handling for RuntimeException."
Also, I am the person who has to implement the service as well as the client. Suppose, if the service is down, how should I handle it at the client side.