Java Reference
In-Depth Information
null value when a pointer was expected, a ‒1 if a positive number was expected, a 0 if either a
positive or negative number was expected, and…well, you get the picture. The idea that there
is an “impossible” value that can be used to indicate an error is not only error-prone in itself,
but also assumes that the value that is returned will never in the future become a non-error
return value. Good luck, by the way, in finding all of the places that the return value is tested
if you ever increase the range of the possible return values. The way out of this was to return
a Boolean from the function indicating whether an error had occurred, and to have any other
returned values passed back as a side effect on one of the arguments that was handed in. This
approach is so common that we no longer have the strong gag reaction that it ought to cause,
and instead see it as a normal way of doing things.
The idea behind the Java exception mechanism is that the error handling should be separated
in the flow of the code from the mainline, non-error code, and that the way to indicate an error
should be explicit rather than built into some convention on what is returned. The return value
of a method should be the result of that method's natural and error-free completion. If an error
occurs, that code should be placed elsewhere, associated with an object that can be used to tell
you what the error was (and, if necessary, tell you more information about the error).
The other notion at the bottom of the Java exception mechanism is that the closer you are to
the point at which the problem occurred, the more likely you are able to do something sensible
about it. We don't expect the code that is throwing the exception to be able to deal with the
problem (if it could, it shouldn't be throwing the exception). But the recipient of that thrown
exception should have to deal with it, or explicitly state that they expect someone farther up
the call stack to deal with it by declaring that they will be throwing the exception as well.
Well, there is one other reason for the design, but it is less often discussed. Programmers tend
to be, if not lazy, at least over-committed. Writing a large system with a lot of programs made
up of lots of classes and interfaces is hard, even if all you have to do is worry about the things
that the programs and classes and interfaces are doing when everything is going right. If you
add in the requirement that the programmer has to think about all the ways that things could
go wrong, and then actually write code to deal with those problems, the task becomes much
more difficult and much more complex. The Java exception design is the way it is in part to
make it easier to deal with these problems. But it is also the way it is in part to ensure that if
a programmer ignores these problems, he does so consciously. If you want to ignore excep-
tions, you have to do so explicitly; just hoping that they never happen won't be accepted by
the compiler. Long experience shows that in a crunch, the only way to make a programmer do
the right thing is to not generate code if he does the wrong thing.
