Re: Error Handling
On 5/28/2010 2:58 PM, Rhino wrote:
I'm trying to figure out some "best practices" for error handling.
Our various recent discussions have convinced me that many error situations
should probably not be handled via Exceptions, particularly things like
input errors on GUIs. I know there is a school of thought that says
exceptions are a reasonable approach to some input errors but that seems to
be the minority opinion; most people prefer other ways.
Don't conflate the program's mechanisms for detecting and
handling errors with the way they are presented to a user. It
doesn't matter to the user whether the original detection of the
error reported it by throwing, or by returning null, or by some
other means: The user just needs to know that the program couldn't
do what was asked of it, plus whatever information might be
helpful in figuring out what to do next.
1. User input errors in a GUI.
[...]
And what would the code in the method that detects the error look like? I'm
picturing if statements that test the input and then format a message if an
error is seen. But what actually gets returned to the calling class?
Presumably, the method that edits the date was going to return a boolean
indicating if the data is good or not but how does the error message get
back to the caller? (At one point, I was writing edits like this to return
an array of Objects; the array always started with the boolean that says if
the data was good or not and, if the data was bad, the second Object would
be an error message. If the data was good though, only the boolean was
returned. Is that a good or bad design? It _felt_ wrong and forced the
calling class to parse the array but it worked okay.)
An array of Object[] is unattractive, forcing the caller through
ugly downcasts and so on. Even BigInteger.divideAndRemainder() is
pretty hokey, IMHO. If you want to return multiple things, it's
often better to write a simple "holder" class to contain them.
Another approach is to pass a "status" object to the method, which
the method can mutate to pass back information about how things went.
See, for example, ParsePosition.
One of the attractions of using exceptions is that they can carry
information of types unrelated to what the code might otherwise compute.
Combined strategies can also be used, along the lines of
Value getValue(String input, Status status) {
...
if (all_went_well) {
status.setValid(true);
return convertedValue;
}
else {
status.setValid(false);
status.setMessage("No comprendo");
return null;
}
}
Value getValue(String input) throws BadValueException {
Status status = new Status();
Value value = getValue(input, status);
if (status.isValid())
return value;
throw new BadValueException(status.getMessage());
}
Also, am I correct in thinking that errors of the kind I am describing
should not be logged, even at a very detailed level, since the log should
only be for serious things that would involve a system administrator? (I'm
tempted to argue that the log _could_ be a place where user errors get
recorded so that people managing the users know which of their people are
having a lot of errors so that remedial training might be provided but I
suspect you will persuade me that that kind of requirement should be handled
differently.)
Most input errors aren't worth logging. Some are: For example,
if the error message is "Invalid username and/or password", someone
might be interested in the fact that seven thousand of them have
been generated in the last two minutes, and might want to find out
something about where they're coming from ...
(Incidentally, when logging authentication failures you might
want to omit the failed username/password combination. Someone
might guess that a failed password is a simple typo for the real
password, and find the latter with a very brief brute-force search.
Also, people occasionally get "out of sync" and enter usernames and
passwords in the wrong boxes, so logging just the username can also
wind up logging some passwords. If you must log them for forensic
reasons, at least encrypt those parts of the log against casual
snooping.)
--
Eric Sosman
esosman@ieee-dot-org.invalid