Best practices when reporting exception messages to the user

In my ASP.NET MVC application, I do not want to report all exception messages to the user. But there are certain types of exceptions that I'd like to report to the user, so I created an action filter to decide if it's this particular type of exception, and if so then display the exception's message, otherwise display a generic message. So I created a custom exception called ClientException.

My filter looks something like this:

    if (filterContext.Exception is ClientException)
         message = filterContext.Exception.Message.Replace("\r", " ").Replace("\n", " ");
   else
        message = "An error occured while attemting to perform the last action.  Sorry for the inconvenience.";

    filterContext.HttpContext.Response.Status = "500 " + message;

I read this http://blogs.msdn.com/b/kcwalina/archive/2007/01/30/exceptionhierarchies.aspx where the author recommends using existing .NET exception types to report usage errors. However, by introducing my custom exception, I just have to do a single check in my f开发者_开发知识库ilter. Is my approach okay?

---

I like this approach for a couple of reasons.

First, it fails safely. If someone doesn't explicity throw a ClientException, then the exception details are not reported. Forgetting to display something is a lesser problem than accidently displaying something.

Secondly, it allows the decision about whether to display the exception to be made at the proper place. Not all IOExceptions are displayed, for example. Some may be, and others wont be. The specific exceptions can be caught and transformed anywhere in the call stack, so that tranformation can be made at a place where it is known to be correct.

Both of those things together mean that a future developer will not innappropriately change a whole class of exception to be displayed, or think that something won't be displayed when it actually will be.

Also, the purpose of the using a particular exception type is to determine later what action to take in response to that exception. "Display this message to the user" is a perfectly good action to specify. Once that decision has been made, then the exact nature of the exception is completely irrelivant. (The original problem may be put in the InnerException property, for logging purposes, of course.)

So, in my opinion, this is a good design.

---

Your approach is fine IMO but there are alternatives. (We're software developers so there are always alternatives.)

You could harness the Exception Data dictionary to store a flag indicating whether or not an exception is a client exception. Then you could have your filter check for the existence of the flag.

---

If your approach works for you then it is fine. And are you surprised that a Microsoft blog is recommending that you use their Exception class? ;)

There are some .NET library features and 3rd party OSS stuff that will only work with .NET exceptions however.

To get the best of both worlds you could always extend the .NET Exception object into your own.

---

I would use different Threshold values based on the type of exceptions, and these Threshold values would be associated with the exception messages.

Based on the particular Threshold value logic you may want to decide whether or not to show exception.

---

My concerns with this solution is that very likely these exceptions will typically be thrown by objects in a business layer (or model objects in MVC terminology). The usage you describe is really what I would consider to be a presentation concern.

Typically you'd need to rethrow whatever exception you have in your model, only to communicate whether or not the exception can be exposed to the user or not. What do you expect the user to do with the information? If the user can fix the situation perhaps there should not be an exception to signal the state to begin with?

I would stick to catching specific exceptions per case and do presentation decisions at the spot. You may send out an exception, as caught, used as model to a view though. I would still let the controller decide, not whomever throws the exception.