I am creating a webservice using the tool( WSAD 5). I am not sure how to pass on the Exception caught at the server side to the client. Suppose I catch an 'GenericJDBCException' on the server side. How can I send the message to the client? So the client would know what Exception was caught and act accordingly.
Kethi, what would you want to give to your clients a service or an exception? It would be much better if you handle this exception on server-side itself and rather pass an error-message and write code according on client. I feel , exceptions are meant to be caught and buried then and there instead of passing on ahead.
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.
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.
Joined: Jun 22, 2005
Never mind, even I am newbie to WS. I am yet to understand this.
Originally posted by M Kethi: ... 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...
If the exception is caught and handled then its caught and handled. It's all over there. Isn't it? Do you expect after the catch block (at server) the exception will still propagate ahead to the client (as RemoteException)? I suspect it may not.
Coming to client, i dont think it should consider in terms of what exactly the exception was thrown on server, all it should be interested is on very abstract level. Just like you said, "Service is not ready" or "Database not connected." Did the service run, if yes then the result, if not then, the reason.
If your service is up and runnig, you can try adding simple class say MyException by extending Exception, try throwing it explicitly, catch it immediately and see if it gets propagated.
Back to "service not ready"... we will have to try that as well.
Joined: Aug 01, 2008
I am working on it. Creating a Custom exception. Will let you if that works. Keep checking.
(110) Connection timed out The remote host or network may be down. Please try the request again.
Were you able to finish up with part-I? what all you were able to follow and where did you stuck up?
Joined: Jun 22, 2005
Well, i had a web-service here which returned a 'result'(String), "success" or "failure". Now, I added these lines in the service method in the very end.
There are no exceptions on my client rather i have the value 'Exception occured.' string returned. !
Joined: Aug 01, 2008
yes. I created a custom exception and my service method throws that custom exception. my client method catches that exception. I am able to get the message i sent. but, when i run the client, it logs the remote exception as well bcos of the checked exception thrown by the server. how could you prevent that? public java.util.Vector getParticipant(int id) throws java.rmi.RemoteException, CustomException
I tweaked it a lot for our purposes but the tip is solid.
Think about how you would like to use a web service, would you really want to evaluate the returned value to check if it contains the message "Exception occured"? Let your code get on with its business, if an exception cocurs it deals with it appropriately.
Using the example...
That looks better than checking the result to ensure success.
Now you might not have a fault for every possible thing that could go wrong, you might have 1 for all your internal errors, like network, database, etc etc. This could contain a unique reference number that your client can query, you look up the number and see the database is down and deal with that. The client doesn't need to know the internals.
You might then have another that deals with specific business validation failures, like that InsufficientFundFault but something generic that could have a code for each type of exception. This is better in some ways and worse in others than a fault for every possible scenario.
Choose what works for you but you can't fatally fault the fault, its pretty useful.