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?

  • "Application stopped unexpectedly. Report this to Microsoft/Apple/etc"? (and then upload full debug info) Commented Mar 17, 2020 at 9:35

6 Answers 6


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)


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.

  • 21
    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. Commented Jun 17, 2014 at 21:26
  • 3
    @JonBentley You're looking at it as a developer, who wants to understand this stuff. The average user will simply become concerned that they should understand it, which they don't need to.
    – deworde
    Commented Jun 17, 2014 at 22:28
  • 13
    @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. Commented Jun 17, 2014 at 22:54
  • 3
    @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
    Commented Jun 18, 2014 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
    Commented Jun 18, 2014 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.

  • 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
    Commented Jun 17, 2014 at 14:55
  • 1
    @piedar: That's a good point. Commented Jun 17, 2014 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. Commented Jun 17, 2014 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... Commented Jun 17, 2014 at 15:30
  • 2
    @NateKerkhofs "And if he's the developer, he can replicate the bug".. - oh, if only that were true :(
    – Blorgbeard
    Commented Jun 18, 2014 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.


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:

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".

  • Well, it is a biased view. The average user doesn't care about why they can't do what they can't do. They only care whether and how they can fix their problem.
    – gnasher729
    Commented Dec 23, 2018 at 18:10
  • "The average user doesn't care about why they can't do what they can't do. They only care whether and how they can fix their problem." If the average user doesn't even understand like what a file or server is, perhaps so, but that might still tie in to what is "actionable" then, because they might be able to tap you on the shoulder and say, "Hey, this application says it cannot find this required config file", or something to this effect, where you might be able to then search for the issue and quickly fix it for them, e.g.
    – user321630
    Commented Dec 24, 2018 at 11:57

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


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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