Arne Vajh?j<arne@vajhoej.dk> wrote in
In most cases I don't think the exception text would
tell the end user anything.
Let us say that you have developed an accounting program and
the code throws an exception telling that it could not
load the JDBC driver.
No point in telling an accountant that. He don't know what
JDBC is.
You tell the accountant that there were a configuration error
and that he should contact his IT department.
You write in the log file what the problem is and when IT
support look at the log file, then they know what the
problem is.
Of course there are cases where the message text from the
exception can be used in the end user error text. Just don't
display class names, stack traces etc..
I completely agree with your argument in this scenario.
I was thinking more of cases where user input is faulty and could be
corrected by the user. For instance, I have a little GUI-based "color
converter" class: it has an input field where I type the hex
representation of a Color, e.g. FFCC00, and it gives me the RGB
representation, e.g. 25, 204, 0, in another field when I click on the
Convert button. Now, if the user mistypes the hex reprsentation of
the color, say FFCCZZ, the method that does the conversion detects
that ZZ is not a valid hex representation of the Blue component of a
Color, throws an IllegalArgumentExpection with text to that effect
(the message is retrieved from a ResourceBundle to allow for
internationalization) and then the try/catch block in the
ColorConverter class displays that message in a JOptionPane so that
the user knows what to fix.
I don't log any of this and certainly don't show the user anything
like a stacktrace; just the message from the ResourceBundle.
That's a reasonable approach, isn't it?