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?