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

My experience with Oracle database is that the error stack contains internal information, such as schema and procedure names and line number(s), which, while useful for debugging, I would like to prevent the user from seeing. Here's an example:

java.sql.SQLException : ORA-20011: Error description here
ORA-07894: at "NAME_OF_SCHEMA.PROCEDURE_NAME", line 121
ORA-08932: at line 10

The string I want to display to user is Error description here. I can extract this string using regex expressions because I know (1) this string is always on the first line, so I can extract the first line of the error stack trace, and (2) this string always begins with Error and ends with the end of the line. [Note for Oracle users (I don't want to mislead you): the above only applies when using RAISE_APPLICATION_ERROR with an error string starting with Error, otherwise the text Error is not there].

My questions for Java are:

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

(2) Are there any formatting rules for the Java error stack trace that I can rely on to extract the non-sensitive information? Or, how to others address this concern?

UPDATE 1:

Thanks for all the replies so far, they've been very helpful. While many people comment to use a function such as getUserFriendlyMessage() to map errors to useful user messages, I wonder if someone could expand on this mapping. That is, for the common errors (SQL, I/O, etc.), what "reliable" identifier could be used to search this error stack for to identify the type of error that happened, and then what corresponding text string would you recommend to map to this error message to show to the user? @Adarshr's response below is a good start. For example,

Identified Expected   If found in error stack, display this friendly msg to user
-------------------   ----------------------------------------------------------
SQLException          An error occurred accessing the database. Please contact support at [email protected].
IOException           Connection error(?). Please check your internet connection.

Assume compile-related errors don't need to addressed, but rather focus those errors that end users might experience during normal use. For reference, here's a list of run-time error messages: http://mindprod.com/jgloss/runerrormessages.html#IOEXCEPTION

Alternatively, is it possible to just use the FIRST LINE of the stack trace to display to user? This link is sort of what I was getting at in my original question above:

http://www3.ntu.edu.sg/home/ehchua/programming/howto/ErrorMessages.html

For example, if the identifier Exception is always used, one could simply extract the text that comes between Exception and the end of the first line. I don't know if we can rely on Exception always being there.

Answer 1

You shouldn't show any of that gobbledygook to your users. It's meaningless to most of them and doesn't help you. As you suspect, it also exposes internals of your implementation that may suggest vulnerabilities that a malicious user might be able to use.

Instead, you should catch exceptions, log them, and show a more comprehensible error message to your users. You can use getMessage() to extract the message part of an exception. If the exception has no message, then show something like "no details available".

UPDATE:

I have some comments based on the question update. First, I would totally insulate the user from any of the internals of your system, both to be kind to the user and for security. (For instance, even knowing that you are using the java.sql package may suggest vulnerabilities to a clever hacker.) So do not use the exception message, the first line of the stack trace, or anything like that when displaying anything to the user.

Second, you should be mapping all errors from the exception level (at which they are experienced in your code) to messages that are at the right level of abstraction for the user. The proper way to do that would depend on the internals of your system and what the user might have been trying to do when the exception was raised. This might mean structuring your system into layers such that each layer that catches an exception translates it into an exception at a higher layer of abstraction. A Java exception can wrap another exceptions (the cause). For instance:

public boolean copyFile(File source, File destination) throws CopyException {
    try {
        // lots of code
        return true;
    } catch (IOException e) {
        throw new CopyException("File copy failed", e);
    }
}

Then this could be used at a higher level in a User class:

public boolean shareFile(File source, User otherUser) throws ShareException {
    if (otherUser.hasBlocked(this) {
        throw new ShareException("You cannot share with that user.");
    }
    try {
        return copyFile(source, otherUser.getSharedFileDestination(source));
    } catch (CopyException e) {
        throw new ShareException("Sharing failed due to an internal error", e);
    }
}

(I hope it's clear that the above code is meant to illustrate the idea of converting exceptions to higher levels of abstraction, not as a suggestion for code that you should use in your system.)

The reason that you want to handle things like this (instead of somehow massaging the message and/or stack trace) is that an exception (for instance an IOException with message "permission denied") may mean totally different things to the user (and to your system) in different contexts.

Answer 2

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.