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

Using this approach, it is clearly possible to completely avoid a DuplicateKeyException
being thrown from addDetails , which suggests that it could be downgraded from a checked
to an unchecked exception.

This particular example illustrates some important general principles:

■ If a server's validity-check and state-test methods are visible to a client, the client will often
be able to avoid causing the server to throw an exception.
■ If an exception can be avoided in this way, then the exception being thrown really represents
a logical programming error in the client. This suggests use of an unchecked exception for
such situations.
■ Using unchecked exceptions means that the client does not have to use a try statement when
it has already established that the exception will not be thrown. This is a significant gain,
because having to write try statements for “cannot happen” situations is annoying for a pro-
grammer and makes it less likely that providing proper recovery for genuine error situations
will be taken seriously.

The effects are not all positive, however. Here are some reasons why this approach is not
always practical:

■ Making a server class's validity-check and state-test methods publicly visible to its clients
might represent a significant loss of encapsulation and result in a higher degree of coupling
between server and client than is desirable.
■ It will probably not be safe for a server class to assume that its clients will make the neces-
sary checks that avoid an exception. As a result, those checks will often be duplicated in both
client and server. If the checks are computationally “expensive” to make, then duplication
may be undesirable or prohibitive. However, our view would be that it is better to sacrifice
efficiency for the sake of safer programming, where the choice is available.

12.9 File-based input/output

An important programming area in which error recovery cannot be ignored is input/output.
This is because a programmer may have little direct control over the external environment in
which their code is executed. For instance, a required data file may have been accidentally
deleted or have become corrupted in some way, before the application is run; or an attempt to
store results to the file system may be thwarted by lack of appropriate permissions or exceed-
ing a file-system quota. There are many ways in which an input or output operation could fail
at any stage. Furthermore, modern input/output has moved beyond a program simply accessing
its local file store to a networked environment in which connectivity to the resources being
accessed may be fragile and inconsistent—for example, when in a mobile environment.

The Java API has undergone a number of evolutions over the years, reflecting the increasing
diversity of environments in which Java programs have come to be used. The core package for
input/output-related classes has always been java.io . This package contains numerous classes
to support input/output operations in a platform-independent manner. In particular, it defines the
checked exception class IOException as a general indicator that something has gone wrong
with an input/output operation, and almost any input/output operation must anticipate that one