12

Consider some code that can throw a checked exception (an exception of type Exception). Your code catches the exception, of course. You don't just swallow the exception either, your code reports it in some way to the user through your user interface. In a log file, perhaps, or using a GUI pop-up.

Should the text you report to the user include the message text of the exception. That is, the text provided by Throwable.getMessage() or Throwable.getLocalizedMessage()?

I think not, but it seems many disagree with me. So what have I got wrong? My argument is as follows.

  • The message was created when the exception was thrown. It therefore at best can provide only very low level information, which can be inappropriate for reporting to a user.
  • Philosophically, using the message seems to me against the whole point of exceptions, which is to separate the detection and initiation of error handling (the throw part) from completion of handling and reporting (the catch part). Using the message means the message must be good for reporting, which moves responsibility for reporting to the location that should be responsible for only detection and initiation. That is, I'd argue that the getMessage() part of the design of Throwable was a mistake.
  • The message is not localised. Despite its name, getLocalizedMessage() is not much good because you might not know what locale you want to use until you catch the exception (is the report to go to a system log read by your English system administrators, or is it to pop up in a window for the French user of the GUI?).
  • I hear that Java 7 has a much improved exception hierarchy for IOException, enabling you to handle different kinds of I/O erors in diffferent catch clauses, making the getMessage() text less important. That implies even the Java designers are somewhat uncomfortable with getMessage().

I'm not asking whether reporting the stack-trace is useful. A stack-trace is only ever going to be useful for an exception that suggests a bug. That is, for an unchecked exception. I think in such circumstances providing the low-level detail of the exception message is not just useful but mandatory. But my question deals with checked exceptions, such as file-not-found.

And I am not asking about the "best practice" for the message text.

Raedwald
  • 46,613
  • 43
  • 151
  • 237

4 Answers4

8

If you are presenting an error condition to the user, it should probably be a user-friendly message. Exceptions contain technical details that the user should not/does not need to know.

In some situations it could be a security concern to present stacktrace information, so the user should never be shown stack traces.

If you are displaying error messages to the user, there is some point where you consciously make the decision to show a popup, or add a message to a log window. At that point you can translate any exception into a more user friendly message. Note that you might need more information than the default Exception types provide, so you can/should probably create you own Exception types that contain all the information you need to present all the data you need to the user.

hvgotcodes
  • 118,147
  • 33
  • 203
  • 236
  • 1
    A stack-trace is only ever going to be useful for an exception that suggests a bug. That is, for an unchecked exception. I think insuch circumstances providing the low-level detail of the exception message is not just useful but mandatory. But my question deals with check exceptions, such as file-not-found. – Raedwald Sep 06 '11 at 12:48
  • In the case where you get an exception because of a serious bug, you would hope that QA detected it. That notwithstanding, if the app crashes, you can display a message that asks users to file a report to reproduce. If you don't have any security requirements around hiding details, than show the stacktrace.... – hvgotcodes Sep 06 '11 at 12:52
7

No, exceptions shouldn't be shown directly in error messages directly to the user, they're low level technical details and the user almost always wants something more understandable, even if it doesn't provide as much information as a stack trace would!

I say almost always because there are cases (such as in IDEs) where you can consider your users technically competent enough to look at stack traces; indeed in this case they will probably prefer it to a "dumbed down" error message.

However, personally I think stack traces should always be logged somewhere that the user can access so that if they complain that "the program isn't working" you can see exactly what went on if they send you that file.

Michael Berry
  • 70,193
  • 21
  • 157
  • 216
5

In some projects, I make a special kind of exception (e.g. UserFriendlyException). This exception type must have a user friendly error message. If I catch such an exception, I can display it to the user.

This makes it possible to use exceptions for user-friendly errors, and prevents that you show very technical messages to the user.

Sjoerd
  • 74,049
  • 16
  • 131
  • 175
  • 2
    That still places responsibility for creating a user-friendly message at the location that `throw`s the exception, rather than the location that `catch`es it. It merely replaces `getMessage()` with some `getFriendlyMessage()`, which does not seem much of a gain. – Raedwald Sep 07 '11 at 12:12
1

I would argue that you should never show the exception message itself to the user, it should only ever appear in a log. Even if you have purposefully made it user friendly, it should still not be displayed because you cannot internationalize those messages easily. You should come up with some mechanism that your UI layer can understand and resolve that to a code that you can look up an internationalized message to display to your user. I have found that an exception with a "code" attribute/enum works pretty well. Very specific exceptions work too, but that can be messy to maintain.

Shane
  • 305
  • 2
  • 6