Re: Exception Handling
Novice wrote:
Are you envisioning that our hypothetical Foo would have a single
FooException that it wraps around everything that percolates up from the
lower levels? Or would there be a bunch of FooExceptions, each handling
different sorts of problems?
Quite often a single exception type suffices. You would only add another if
there were a crying need for it.
And what happens with logging? Do we just log the error as an
IllegalArgumentException (or whatever) when we find it at the low level?
Did you read Patricia's advice on this very matter?
Or do we also log it again, this time as a FooException, when we deal
with it at the higher levels? I'm uneasy about writing what are
effectively redundant messages to the log.
Patricia recommended, and I agree, that the custom exception serve as a signal
that the lower-level problem has been logged. Remember?
For what it's worth, I've cobbled together a CrashDialog class which my
higher level methods, getLocalizedText() for example, displays when it
handles an IllegalArgumentException() if it is thrown by getResources().
(I'm now throwing IllegalArgumentException for nulls in the parameters as
well as a failed getBundle()). In that case, the CrashDialog class says:
Is a failed 'getBundle()' really a programming error? Is it really an illegal
argument? There was nothing illegal about the argument /per se/ if the
resource just happened not to be available.
I suggest a checked exception, either 'IOException' or a subtype thereof, for
a missing bundle, unless it really and truly is completely under programmer
control. (And deployment-time issues never are.)
===================================================================
Foo - Severe Error
The program has to stop for the following reason: Certain language
resources were not available.
The problem has been logged and Technical Support will begin resolving
the error shortly.
[Okay]
====================================================================
The line about Technical Support resolving the problem shortly is
somewhat fanciful since I'm the whole development team and the entire
universe of end users at the moment ;-) I'm just envisioning what I'd say
in a real production application.
Be careful of making promises because you must keep them.
Well, technically you don't have to, but do you want to be that guy?
The bit about the language resources being unavailable is not completely
satisfactory because it is probably not very helpful to a non-technical
user but it seemed better to summarize the situation than to use the
message from the exception; the user is even less likely to comprehend
"the baseName must not be null" or "Unable to find resources for base
name, com.novice.foo.FooTextzzz, and locale, jp_JP. Check the spelling of
the base name". And I certainly don't want to display a stacktrace to the
user!
I've also logged the fact that the user clicked on okay to end the
program as another SEVERE error. Mind you, that seems redundant and I'm
How is that any kind of error?
inclined to remove that code again. I'm assuming that in the real world,
one SEVERE error is going to be enough to get the attention of the
appropriate people and producing two or three SEVERE errors about the
same problem is not going to get the problem examined any sooner. Correct
me if I'm wrong!
Don't worry, we will.
But you have a brain. What makes sense there? What would look funny to the ops
guy?
Are you really thinking like a troubleshooter in the field, or like the
programmer whose name that troubleshooter will curse?
Now, that behavior wouldn't be standard for all cases. If the error is
recoverable, the user would get different instructions that would lead
him/her through whatever needs to be done to recover. And some errors
might not be severe at all and just be informational. In those cases, the
dialog might say "Information" instead of Severe Error and simply
describe whatever workaround Foo adopted to get past the problem.
I'm feeling good about the error handling and logging now. It's starting
to fall into place for me, aside from the whole custom exception
question.
What do you mean by "recoverable"? I mean able to show an error dialog and
invite the operator to shut down. Is that not a valid program state?
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg