Java: what information in error stack trace do we typically not wish to show users?

Question

I\'m new to java and I\'m not that familiar with the formatting rules used by an error stack trace when it is thrown and subsequently displayed to an end-user of my web appl

Answer 1

Usernames and passwords are obviously sensitive information that you wouldn't want to show to the user. Also, like you said, file system paths, server names, and IP addresses should be hidden as well.

The Exception.getMessage() method will return just the message of the thrown exception and not the entire stack trace. But it looks like in the example you gave, the 2nd and 3rd lines are also part of the exception message, so that doesn't help you.

BUT it's not Good Practice to ever show your users stack traces. Not only can they contain sensitive information, but to the user, they're about as readable as Klingon. You should be logging all uncaught exceptions instead, and then displaying a more user-friendly message to the user.

Answer 2

As others have said, you should not report the stack-trace to users. Several others have suggested you display the getMessage() text. I recommend not doing that. As I've said before:

• 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?).

Answer 3

You should not show any information to your end users that they cannot understand, which includes all of the stack trace in its entirety. The error you should show when you catch an exception like that should read something like this, in the language of your end-users:

• Our program has experienced temporary difficulties. Please call technical support line for assistance.

End users couldn't care less about your program's inner organization, databases, stacks, et cetera. All they know is that something that they thought should have work just failed, so they are looking for assistance.

Stack traces are for error logs: you can save them for yourself, or e-mail them to technical support, but you do not want to show them to the end users.

Answer 4

The string I want to display to user is Error description here.

You can use Exception.getMessage() for this purpose, though as Juan Mendez suggested, consider implementing a more "user-friendly" error message mechanism for displaying errors to the end user.

If you don't want the end user to see the names of your classes, methods, and fields in the stacktrace, consider using an obfuscator like Proguard. I like to print obfuscated stacktraces in log files, then use ReTrace to unobfuscate them for debugging purposes.

(1) Is there anything potentially sensitive that you wouldn't want users to see in the error stack? If so, what? For example, file paths, server name/IP, etc.

It can depend on the exception being thrown, I think. Choosing to log the exception or not is a tradeoff between application security and being able to effectively diagnose the problem, I take it on a case-by-case basis, and leave comments as necessary to explain my reasoning for logging or not logging it.

Answer 5

Do not show the exception message / stacktrace directly to the end user. Instead try and use an Exception - Message mapping approach.

For example:

• SQLException - Sorry, a database error occurred. Please try again later
• RuntimeException / Exception - Sorry an error occurred. Please try again later

In fact, you can make it as generic as possible. Perhaps you could use a custom error code mapping. For instance, E0001 for SQLException, E0000 for Exception and so on and display this to the end user. This will be helpful when they eventually contact the customer service with the error code.

Answer 6

You should only show stack traces when your app is in debug mode. In production mode, you should show a generic error message (or implement an Exception.getUserFriendlyMessage())and log the error (provide a log id if possible).