Alternatives to Throwing Exceptions to Flex/Silverlight Clients From a .NET Web Service – part 1
I’ve been doing a lot of work with webservices talking to Flex clients recently. When I first started doing this work I spent some time trying to figure out how to get exceptions thrown to be picked up by the client and dealt with there. I read through the literature on doing such things, and even spent some time evaluating some third party libraries for making all of this happen.
Recently I was at a .NET users group meeting and heard some people talking about throwing exceptions to Silverlight clients in much the same way that I had been looking at doing for my Flex clients. The problems that they encountered and the solutions that they came up with were essentially the same. “IIS does dumb stuff with the response codes when there’s an exception in a webservice”. (There’s a pretty simple work around for this one ) “You can trap the exception and then make the exception object a property of the service response object”, “There’s a third party product X, that wil…blah blah blah”. It was nice to see that noone had come up with an elegant solution to this “problem” of throwing exceptions over the wire.
I started to wonder if it really was a “problem”. I took a step back and did some critical thinking about such an approach. I had a lot of questions about what I, and the rest of the people out there are trying to accomplish by throwing exceptions “over the wire”.
- What benefits do you get from handling server exceptions in the UI?
- Is it really correct to handle exceptions in the UI for problems that occurred in the web service?
- What are the valid uses for exceptions?
- What is the definition of an exception?
- What are people trying to do with these exceptions?/ What problems are they trying to solve by the use of exceptions?
In an effort to clear up my thinking on such things I’m going to go through some of the above questions below.
What is the definition of an exception?
The tongue in cheek response to this question is “it’s when something exceptional happens”. The longer explanation is that when your code encounters something that that is outside the scope of what it was intended to handle. I think there’s a clue in there that addresses the problem I’m trying to deal with, but we’ll have to get back to it after we talk about a few more of the questions.
What are the valid uses for exceptions?
Answering this question is difficult without having a problem domain to work with. The answer can vary depending upon the environment that your code is expected to run in, how reliable various parts of the environment are, how critical certain operations within your application are, etc..etc.. What I would like to say about this is that like we said above your exceptions should handle exceptional situations.
I also think that there is often too little thought put into the implementation of exceptions within an application. There’s a pretty good argument floating around that your exception model should be diagrammed and managed in the same way that your business objects are. I might talk about this at a later date, but for now give it some thought.
Is it really correct to handle exceptions in the UI for problems that occurred in the web service?
In a windows application that is self contained, handling exceptions in the form code seems to be something that a lot of people are comfortable with ( judging by the codebases I’ve had to maintain ). In fact most books that I run across that show beginning development have the exception handling directly in the form itself. This is arguably correct, if not desirable, for quick and dirty applications, because you’re really just trying to get something done. Besides you don’t want to throw the actual exception out to the user to look at so you catch the exception and give the user a nice “Something really bad happened, try again” message and exit the application.
Now in a situation where you have a client application talking to a server application. You have a different scenario. The server is providing services to the client, if something bad happens in the server it should handle the problem in some way, (i.e. capturing the exception ) and then notify the client that there has been an error.
In the same way that you would never want to throw raw exceptions from your self contained application out to your users. You really don’t want to throw raw exceptions to the clients that use your server API. If there was a problem with your server code handle it gracefully in your server code and provide your clients with a decent error message.
There should be a separation between your server code and your client code, when you start to throw exceptions from your server out to your clients you begin to tie them together in ways that are not extensible. Consider if you start using a new library in your server code that throws a different type of exception that you felt should be bubbled out to your client. This means that all of your clients will need to be updated to handle the new exception instead of handling a “call failed” response sort of message. Encapsulation is a metaphor for good design at all magnification levels of developement not just at the object/class level.
There is more I could say here but I’m going to move on for now. I might come back and talk some more about this in another posting.
What are people trying to do with these exceptions?/ What problems are they trying to solve by the use of exceptions?
From what I’ve observed most people are trying to ease their burden on the server side by throwing exceptions out to the clients when there are problems. The most common example of this is input validation, or even a little deeper would be business object validation (i.e. Does this user have the right to add another user to this account ) Call me crazy but I don’t see how you can call a user entering incorrect values to be an exceptional situation. At least with my users it never is. If there is a wrong value that can be typed, they are going to type it. I don’t start throwing exceptions and stepping out of the program flow to deal with these errors because they are not exceptional circumstances. I have a really hard time believing that validation of input is a good place to start throwing exceptions. Yes, the system should reject bad input, or illegal operations but do you really need to start throwing exceptions over the wire to deal with this? Is it necessary to tightly couple your UI code base to your server codebase just to get the proejct done and avoid duplication of validation efforts?
I really don’t think so.
In the next part of this article I am going to provide some diagrams, patterns and maybe even a little sample code to show how you might avoid “exceptions over the wire”