Tired of looking for errors in log files? Use OneTrueError - Automatic exception management for .NET.

Dealing with exceptions, Logging and displaying error messages

I got a client which is really firm on that the user should know what went wrong when exceptions are thrown. So we are displaying error messages like

“The database did not respond”
“The database operation failed”
“Failed to load configuration setting X”

etc etc.

If it were just me, I would simply just print something like:

“Oops, something unexpected happened. Please try again or contact the support department”

Why?

Ok. So let’s assume that we show the user a more detailed error message. What is he/she supposed to do with it? Remember, it’s from an exception. If something exceptional happens it unlikely that the user can fix the problem by reading an error message. At tops the user can try do perform the operation again.

When the user have got tired of trying he/she calls the support department. If we’re lucky the user manages to quote the error message exactly. But really. Do that help us? Not really. We still have to go through our logs to find out what happened.

The correct approach to dealing with exceptions

So what should we do when an exception happens? Well. Try to prevent it from happening in the future. That goes for all exceptions. Some can be prevented, whilst others can’t. The point is that we should at least try.

To be able to try to fix the exceptions we have to find them. Using a big fat log for everything is not a very good way. Instead try to have a seperate log for all unhandled exceptions. Make sure that you read that log. You might want to build something that emails that log to you daily.

This entry was posted in Architecture, CodeProject and tagged . Bookmark the permalink.
  • http://www.daedtech.com/blog Erik Dietrich

    I like your points about not having a “fat” log file and that the user is unlikely to know what to do with very fine grained exceptions. However my opinion is that there might be some validity to having a granularity finder than “oops — please contact devops” or whatever. What if instead of “database did not respond” we had “could not connect to the database”? This might clue a reasonably savvy user into a dumb mistake (oops, I didn’t turn on my wifi radio) that he could correct. The generic message would be less likely to do that.

    A matter of degrees, I suppose. Could be that what I’m saying here is more edge case than worth preparing for.

    • http://www.gauffin.org jgauffin

      Thanks for a well motivated comment. I do agree with you. But imho we should start with generic error messages and then let user experience drive those messages forward. Because of if we, as engineers, try to think of which cases we should use specific errors for we’ll likely end up with too technical error messages.

      There are of course exceptions. If you’re coding a client which is dependent of a networking connection you’ll probably add a “check your network connection” error. But you’ll probably show that message after checking the network connection and not because you got a uncaught exception.