Handling errors - Objects First with Java: A Practical Introduction Using BlueJ - page 425

Exercise 12.22 Does a constructor have any means of indicating to a client that it cannot
correctly set up the new object's state? What should a constructor do if it receives inappropri-
ate parameter values?

Clearly, an out-of-bounds value cannot be used where all values from the return type already
have valid meanings to the client. In such cases, it will usually be necessary to resort to the
alternative technique of throwing an exception (see Section 12.4), which does, in fact, offer
some significant advantages. To help you appreciate why this might be, it is worth considering
two issues associated with the use of return values as failure or error indicators:

■ Unfortunately, there is no way to require the client to check the return value for its diagnostic
properties. As a consequence, a client could easily carry on as if nothing has happened and
could then end up terminating with a NullPointerException ; or, worse than that, it could
even use the diagnostic return value as if it were a normal return value, creating a difficult-
to-diagnose logical error!
■ In some cases, we may be using the diagnostic value for two quite different purposes. This
is the case in the revised removeDetails (Code 12.3) and getDetails (Code 12.4).
One purpose is to tell the client whether its request was successful or not. The other is to
indicate that there was something wrong with its request, such as passing bad parameter
values.

In many cases, an unsuccessful request will not represent a logical programming error, whereas
an incorrect request almost certainly does. We should expect quite different follow-up actions
from a client in these different situations. Unfortunately, there is no general satisfactory way to
resolve the conflict simply by using return values.

12.4 Exception-throwing principles

Throwing an exception is the most effective way a server object has of indicating that it is
unable to fulfill a call on one of its methods. One of the major advantages this has over using
a special return value is that it is (almost) impossible for a client to ignore the fact that an
exception has been thrown and carry on regardless. Failure by the client to handle an exception
will result in the application terminating immediately. 1 In addition, the exception mechanism is
independent of the return value of a method, so it can be used for all methods, irrespective of
the return type.

An important point to bear in mind throughout the following discussion is that, where excep-
tions are involved, the place where an error is discovered will be distinct from where recovery
(if any) is attempted. Discovery will be in the server's method, and recovery will be in the cli-
ent. If recovery were possible at the point of discovery, then there would be no point in throw-
ing an exception.

1

This is exactly what you will have experienced whenever your programs inadvertently died because of a
NullPointerException or IndexOutOfBoundsException .