How much information about an error should be shown to the user?

Question

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?

Answer 1

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

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.

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

What you want to show depends on how ashamed you are for screwing up.

The point is to get the details of the failure to technical support as quickly and smoothly as possible. That may mean you send the log file including the stack trace of the terminating error back home automatically or you kindly ask the user to click a button which will initiate the transfer. Maybe through USB stick if there is no internet connection.

Answer 6

I like the rationale behind the accepted answer, but I must respectfully disagree at least with my interpretation of limiting the information to what is "actionable". I want to know just a little teeny bit more than that as a user than "unexpected error".

And admittedly I am a bit computer-savvy and I have that bias, but I don't think this is a particularly biased view. Because I can try my best to remove that bias by applying this mindset to domains for which I have little expertise, like aviation.

While I know little about aviation, say my flight is delayed or canceled and the only thing the staff tell me is, "We had an unexpected error. Please wait 3 hours for a subsequent flight." You'll at least find me a bit more of a disgruntled customer in those cases because, even though it doesn't really affect my course of action either way, I just want to know just a tiny bit more about why I'm being inconvenienced this way as a paying customer.

If they just said like, "We're experiencing turbulent weather," or "We had a medical emergency in our previous flight," or an equipment malfunction or whatever, that's plenty enough for me to sympathize much more than "unexpected error" and be a little more content sitting around and waiting 3 hours for the next flight. Actually I might even prefer some technobabble that goes over my head to "unexpected error" like, "All right, the words coming out of your mouth are going into my ear but not reaching the central processor. But I get now that there's some sort of issue there and I'ma go grab some coffee and sit over there! Hope you guys get that issue sorted out with that thingamajig!"

And often in terms of exception-handling, I think you usually have enough of that kind of basic info of what happened at the catch site, even if you want to hide the more technical details of the exception, like:

try
{
     load_file(file_name);
}
catch (const exception& ex)
{
     exception_dialog("Failed to load file: '{1}'.", file_name);
}

And that's not even displaying what might potentially be the very technical information attached to the exception, but it's at least telling us considerably more than "unexpected error". It at least provides a contextual "what/where/when" even if it doesn't say "why/how". I think at least the desire for this basic level of info is not particularly biased by my computer-savviness.

The rest is probably very specific to your customers and particular needs. But my appeal is at least for something just a teeny bit more than "unexpected error".