DevOps Zone is brought to you in partnership with:

.NET developer/architect. Been coding since 1996. Jonas is a DZone MVB and is not an employee of DZone and has posted 15 posts at DZone. You can read more from them at their website. View Full User Profile

Dealing with Exceptions, Logging and Displaying Error Messages

01.19.2013
| 4208 views |
  • submit to reddit

I have a client who is very firm on the idea that the user should know what went wrong when exceptions are thrown. So we're 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?

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.

Published at DZone with permission of Jonas Gauffin, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Lund Wolfe replied on Sun, 2013/01/20 - 3:30am

Use exceptions to your benefit and the customer's benefit.  I assume I'm the user, and sometimes I am.  Even when a website unintentionally displays a database exception message, at least you know what went wrong and why you don't see the expected result.

With detailed info you can often go right to the problem in the code and fix it.  The user may have sufficient info to fix his own data or work around the problem immediately.  Maybe the mail server or database server is down.  Not everything is your fault and you can't fix it, but you can tell the user to try again later.  You won't be able to reproduce every user issue (especially when the combinations of data and code paths are endless), so messages and logging right on the client is a good thing.  The more the user knows the better.  The user is your friend.  Have faith in them and faith in yourself to acknowledge and fix the problem.

Your code is not perfect, and you don't know where it is not perfect, so assume it will fail and display the details of the problem as best you can to the user.

Oleksandr Alesinskyy replied on Wed, 2013/01/23 - 5:31am

 "“Oops, something unexpected happened. Please try again or contact the support department” is less then satisfatory. It shall look like this

“Oops, something unexpected happened. Please try again or contact the support department and provide this ID 28950001”. Where 28950001 is more-or-less unique for this incident,

Jonas Gauffin replied on Thu, 2013/01/24 - 3:41am in response to: Lund Wolfe

With detailed info you can often go right to the problem in the code and fix it.  The user may have sufficient info to fix his own data or work around the problem immediately.

In my experience that's only true for applications which are poorly tested. i.e. some basic errors like a field which is required was not specified as required (so that a validation error gets back, or worse: the SQL query error message complains on it).

I'm not really against displaying exceptions. But I've seen a couple of applications which formats the exceptions so that they should contain information specific for the user (and not the developers). That makes the exceptions part of the business flow (and not a tool to help the developers solve flaws in the application). That's really damaging, since it makes the developers feel like exceptions are OK and not not something exceptional that they should focus on fixing.

Let's take your example with the mail server or database server. There is absolutely nothing that the user can do with that kind of information. If the DB or the mail server is down, do you think that that information would increase the understanding of why your application are not working? I think not. imho it's better to notify the support team and just display a "sorry" page to the user.

Jonas Gauffin replied on Thu, 2013/01/24 - 3:44am in response to: Oleksandr Alesinskyy

That's a great idea since it makes any customer support contact a lot smoother for the user. It's not very hard to map the error/exception info to a new ID either.

Hi! 

I tried buy the new Avicii album but got an error with id 28950001

Oleksandr Alesinskyy replied on Thu, 2013/01/24 - 6:42am in response to: Jonas Gauffin

 "There is absolutely nothing that the user can do with that kind of information."  - unfortunately, there is something. Namely, this kind of information is of a great use to a malicious user that wants to hack your application.

Oleksandr Alesinskyy replied on Thu, 2013/01/24 - 6:44am in response to: Jonas Gauffin

I meant ID per incident, not per error/exception type. And yes, it is a lot smoother for both the user and the customer support (we have this functionality in our systems for years).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.