In a client-server relationship, should the server always reverse the exception to the client?


I have a set of web services (the server), and an app which consumes this (client). In this sort of relationship, should the server always throw exceptions (ie in the throw block, rethrow the caught exception), and the client catch this. Exceptions which the server can handle, it will deal with and not rethrow, but everything else will be thrown to the calling layer for further action (the consuming app can raise a msg box or whatever).

Is this a good example of an exception that can be dealt with: A file cannot be written because the directory requires special privileges, so if this raises an exception, the file is written somewhere which does not require admin rights.


There are more than one type of error.

  • For errors that the client can correct and retry, give them instructions on what to correct.
  • For other errors, where retrying will make no difference, such as an unauthorized action, let the user know why they can't perform the action, and if there's anything they can do to change the matter.
  • As you suggested, if the client issues a request to update the record, and something on the server, out of the control of the client, occurs, but the server can recover, then don't notify the client. If you need to know, then have the server notify you.
  • If the error occurs on the server, but the server isn't able to recover, you definitely need to notify the client of the failure and to either notify you, or try again later. Again, the system should notify you.