Server Errors

When writing a client app, we can lump server-errors into two broad categories:

Exceptions - the code running on the server has failed in an unexpected way. Examples:

• The server-code cannot write to or read from disk.
• The server operation violated a constraint in the database.
• The server cannot find a matching method signature for your request.
• and so on.

Business Errors - The request violated a business rule in our application.

• An account with that email address already exists.
• The submitted data is not valid.
• We cannot lend you "Breakin 2 Electric Boogaloo", you already have that video checked out.

In my opinion a server exception should never be pitched to the client for at least two reasons:

1. exceptions often expose sensitive information, and
2. the server-code ought to handle the exceptions in question; not just re-throw them.

Now the server certainly needs to let the client know something went wrong, but that response need only indicate the severity of the exception and whether or not the client should try again.

Consider the case where a user uploads a corrupt file and the server throws an exception while trying to read it. In this case the client ought to inform the user that their file was malformed and to try again. If user-input from the client causes a violation of a database constraint however, then the software has failed and there's no point in allowing the user to retry their operation.

Back to the two categories of errors, Exceptions and Business Errors, which do you think the client should handle?

Both? Hell yes both! Here are a few ways to recover:

Recovering from Exceptions
If the exception is fatal, the server should send a text message to the poor bastard(s) on call and return the fatal-status to the client. The client could then display a standardized alert, much like the following:

We're sorry but we've encountered an error , please try again later. We apologize for the inconvenience, the support staff has been notified and is working to resolve this issue. If you have questions, please contact our support staff at support@domain.com

The user would then be logged-out for the application is no longer stable. This of course is a severity 1, high-priority, wake-your-ass-up-and-fix-it issue. Have I mentioned how much I hate maintenance? At any rate, say a user uploaded a corrupt file causing a server exception and we'd like for the user to try again. Our Alert might read:

We're sorry but we've encountered an error processing the file you uploaded. Please fix the file, or try uploading a different file. We apologize for the inconvenience. If you have questions, please contact our support staff at support@domain.com

Recovering from Business Errors
This actually varies depending on the error, but it is worth noting that the server ought to return a code indicating the error in question so the client can proceed accordingly.

I've used variants of the following server-response object on lots of projects with success:

A useful result object

When I get one of these back from the server, I check the operationStatus first and if its OK, I parse the result property. On "error" I then see if I need to try again (and often keep a count of how many times I've retried) and use the "faultCode" to drive my message to the user. On business errors, I check the businessStatus and notify the user accordingly.