Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Applications can always throw errors. If such an error occurs, the user should be notified, because what he asked the application to do has not succeeded.

However, how much information should the user be given? I think most of us agree on not showing a stack trace (Should a stack trace be in the error message presented to the user?), but I can't find a question about the rest of the error contents or what to show to the user.

For example, a language supporting exceptions (.net, java) has the exception type to share, where the exception occured, and a somewhat clarifying message to go along with the exception. Should this also be hidden from the user? Or should we show this anyway? Or should we show a generic message? or should we show one of a number of messages based on what the underlying exception is?

share|improve this question

4 Answers 4

up vote 29 down vote accepted

what to show to the user. Should this also be hidden from the user?

You show the user what is actionable for them.

For example, if you have an error which is caused because of some null pointer exception and more of a bug than user error you don't want full explanation because they can't do anything different.

Or should we show this anyway? Or should we show a generic message?

Showing the exception as the primary error message content is pointless for most users. Perhaps if your target user base is developers you could show the information as the full error all the time (maybe you have an internal application for automated testing). But generally users cannot do anything different even with that knowledge.

should we show one of a number of messages based on what the underlying exception is?

The best strategy is to do the following:

  • Interpret the error into text which is meaningful for the user.
    • Part of this is "what can the user do differently?"
    • If they can't do anything different, say something like "an unexpected error has occurred."
  • Add an "optional" detailed error description
  • Allow users to submit the error report (or do this automatically, depending on user base)

Example

enter image description here

  1. It shows the "here's what happened" (unexpected error)
  2. Tells user what to do (reopen Mail, even includes a shortcut to do this)
  3. Also has a "view details" if someone is curious to see the full technical error
  4. Provides notification an error error report is filed (see below)

Note that in some cases you may wish to make the error report be manual vs automatic.

share|improve this answer
1  
This should be on UX.SE! Nice answer. –  Ayesh K Jun 17 at 20:29
14  
I disagree. There is nothing quite as intensely annoying as an application which prints "an error has occurred." to the screen and then exits. Whenever that happens, I always wonder why the developer was so lazy as to print such an uninformative message. Explain something to the user so that they can understand what went wrong in a general sense, even if there's nothing they can do about it. Best case scenario, they can Google the error message and perhaps find a solution that someone else has described, which is almost impossible if every different error prints the same generic message. –  Jon Bentley Jun 17 at 21:26
10  
@deworde On the contrary, I am considering it as a user. As a user, I do not want to understand it in technical terms, but I want enough information that I don't feel like the person who wrote the software is incompetent ("an error has occurred" gives the impression that the developer didn't know what they were doing), and so that I can search for answers. If every single crash says "an error has occurred" then a Google search is not going to help me. A unique message for each situation is far more likely to get me to a forum where someone else had the same problem, and maybe solved it. –  Jon Bentley Jun 17 at 22:54
2  
@JonBentley a few points for consideration. First, the primary point of this answer is you give the user actionable information. If it's an error they can fix need to tell them information to resolve it. This falls into You show the user what is actionable for them. If you know the cause of the problem, then you show that to the user in the description. But generally if you know the reason for an error you will know the problem resolution to inform the user appropriately. –  enderland Jun 18 at 3:43
2  
Second, you grossly overestimate average user ability to self-resolve problems. The overwhelming majority of the population is what most developers/programmers/Stack Exchange folks would call computer illiterate. Most of these people quite frankly are not equipped to diagnose, troubleshoot, and resolve problems. Detail can actually make things worse because people can misinterpret things which would make complete sense to developers. Programmers and tech savvy people are almost universally not the target demographic for most applications, much to the disappointment of everyone here... :) –  enderland Jun 18 at 3:46

It depends on who the user is, and what they can do with the information.

Generally, try to show them only useful information about things they can resolve themselves. A 40 line stack trace with a regular expression error at the top is not very useful. Much better would be a message that says Date must be formatted as "yyyy-mm-dd". Anything else, and the user might not know how to respond to the error, and then they might not want to use your application, for fear it will cause more cryptic and frightening errors (and yes, non-technical users are sometimes frightened by stack traces). And that might be bad for business.

For internal applications used by other developers, I'm a little more relaxed about displaying a stack trace, in addition to something more useful, because I know the user can handle seeing a stack trace and will probably know what to do about it.

For non-technical users, the only time I think it would be OK to show them a stack trace is in a critical error situation where you need it to resolve the problem, and they are asked to copy and paste the stack trace and send it to you, although really a much better way to do it is to ask them to send a log file, or better yet, have the application send a log file to the developer, after asking the user for permission to share the file.

share|improve this answer
5  
I would not be OK with an application that sends logs anywhere without asking me. Instead, the error message dialog should provide an option to report the error. The user should be able to review any and all info, including the stack trace, before sending the report. –  piedar Jun 17 at 14:55
1  
@piedar: That's a good point. –  FrustratedWithFormsDesigner Jun 17 at 15:05
4  
@piedar: Having a "See more details" button in the error dialogue, or a link to the application log file is probably a good way to present all the gory details to the powerusers who want that info. Even a "show details by default" checkbox, if you want to go to the trouble of coding it. But not all users will want to see that, and some users will be turned off by that. –  FrustratedWithFormsDesigner Jun 17 at 15:16
2  
@Paddy: You're correct, but: 1) It's an example. :P 2) Maybe I've been fixing and cleaning up such code, which is why it's fresh on my mind... –  FrustratedWithFormsDesigner Jun 17 at 15:30
2  
@NateKerkhofs "And if he's the developer, he can replicate the bug".. - oh, if only that were true :( –  Blorgbeard Jun 18 at 4:45

Messages to the users should be treated in the same manner as creating a new exception to throw -- you provide the information they will need to decide what to do.

This will of course depend upon your application and userbase, but it should be your guiding principal -- your intent should be to provide the information needed for the "caller" to determine what, if anything, they can do to sucessfully perform the desired action. If it's something simple like an access error to a file, you give a file path and the message that you couldn't access it. If it's a null pointer exception, just give a generic error message.

Of course there are going to be more "unable to perform the desired action" messages than there will be ones that the user can actually fix, but that's just life - most exceptions are because we made a mistake, not because the user setup the environment incorrectly.

share|improve this answer

This is a common theme:

How can you help the uninformed / computer illiterate at the same time as showing information that more advanced users such as programmers, developer, testers, etc. can use.

I think the answer is you do both!

The order is important though and I recommend you have:

  • What happened.
  • What to do now
  • Technical Details

Technical Details is the part that has information for either advanced orders or for regular users when reporting an issue

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.