If you don't have a Global.asax in your project that hosts your REST services, add one. Make sure it has this method in the code behind file: With ASP.NET, this is your global error handling. Anytime there is an unhandled exception, this method will be called. The following code block shows how you can get the exception that was thrown, do some logging, and then clear the error (clearing the error prevents the yellow screen of death from being sent to the client). The code below handles all scenarios (both a RestException, or any other kind of exception, which we just wrap up in RestException and write down to the client). Note that you only want to clear the error if it was indeed handled. Since modern web applications are so heavy on the client side script, you'll probably want to send some kind of indication down to the client that an error occurred. With RestCake, you can make use of the RestException class to make this quite painless.

Anytime there is some kind of processing error in RestCake (a method expects an int and it's called with a string), the methods in the RestHttpHandler will throw a RestException. Since it's unhandled, you'll end up in Application_Error(), and Server.GetLastError() will give you that RestException. However, you can throw your own RestExceptions from your service methods as a way to send validation error messages back to the client. Now you don't have to throw a RestException all the time. Perhaps you would prefer to throw an ArgumentException in the above case (that's how it is in the actual AddressBookService.cs file in the examples). That's ok too, you'll still end up in Application_Error, and you can deal with different exception types however you please. If, as shown in the example Application_Error above, you just end up wrapping all other exception types in a RestException and sending it down to the client, then it might be better to throw more specific exception types in your service methods. If you plan on holding back other exception types from the client, and just sending back a generic error message (for security or other reasons), then you might want to throw RestExceptions directly for validation messages, and handle them specifically in Application_Error. It's up to you.

All of the dynamically created javascript proxies use a base proxy class that handles the error callbacks. If you look in the WcfProxy.js, you'll see something like this in the default error handling that's provided when we initially setup our jQuery $.ajax() options: Wow, 6 arguments are sent to the user's error callback? Really? Well, you don't have to use all of them. In fact, with javascript being so dynamic, you don't even have to declare all of them. Most of the time, you'll only need the first one. The userContext arg is only there if you use it, and the next 3 (xhr, textStatus and errorThrown) are all given to you from jQuery, so I just pass them along in case they'll be useful. The last one is just the content-type of the response from the server.

So here's a full example of how we could set up some error handling when calling a service method from one of the javascript proxies.