8.8. Dealing with Deviations and Errors

8.8. Dealing with Deviations and Errors

As discussed in Chapter 3, any system has to deal with deviations and errors. Deviations are those conditions that can be expected to occur in normal processing. Errors are those conditions resulting from hardware or software malfunctions.

8.8.1. Signaling Errors and Deviations

Tim and I separated the conditions that occur during processing into errors and deviations. We needed to decide how to signal each type of condition. Errors from hardware and software malfunctions are generally not expected, so exceptions provide a clean way to handle those conditions. To signal deviations some groups prefer using exceptions and other groups prefer using return values from methods . Tim and I chose exceptions, since that is the common paradigm in Java.

8.8.2. Deviation Conventions

The com.samscdrental.failures package contains deviations and exceptions:

Deviation.java

    CDCategoryFormatDeviation.java

    CheckInDeviation.java

    CheckOutDeviation.java

    CustomerIDFormatDeviation.java

    DollarFormatDeviation.java

    ImportFileDeviation.java

    ImportFormatDeviation.java

    LateReturnDeviation.java

    NameFormatDeviation.java

    ParseLineDeviation.java

    PhysicalIDFormatDeviation.java

    PrinterFailureDeviation.java

    StatusDeviation.java

    UPCCodeFormatDeviation.java

    SeriousErrorException.java

To separate deviations from exceptions, all expected errors are derived from Deviation , which in turn is derived from Exception , the base class for Java exceptions. The Deviation object contains an explanation that gives the user an indication of the error. For example, when converting from String to CustomerID , if the format is invalid, the CustomerIDFormatDeviation object that is thrown contains the reason.

Find methods for collections in Java return null if a matching object is not found. "Consistency is Simplicity" suggests that the collections in Sam's system also do so. If CustomerID is not found in CustomerDataAccess , the find method returns null . This situation might be a permanent error if the customer was removed from the collection. It might be a failure due to an error in inputting CustomerID . We might add a check digit or other error checking on the CustomerID to ensure that the string value is input correctly. That way, we would deal with the failure as close to the source as possible.

We created the SeriousErrorException class, which is an unchecked exception. An unchecked exception does not have to be indicated in the throws clause for a method. A method throws SeriousErrorException when an error occurs of such severity that the program should not continue. The exception represents bailout . There is no need to catch SeriousErrorException in intermediate methods. The user can do nothing to fix the problem indicated by the exception. The main program catches SeriousErrorException and displays its description to the user and then exits. If the user could do something to fix the problem, we would not exit the program, but allow for a retry .

8.8.3. Errors When Importing a File

Importing a file provides a whole series of errors that need to be handled. The interface contract (see Chapter 3) for the import needs to be spelled out in some detail. For example, when the file is read, what should occur if the file has bad or incorrectly formatted text in it? Should the program reject the entire file or just ignore the line with the incorrect format? When we are parsing the strings in the input file, we might get multiple errors on each line or we might have multiple lines with errors. Do we report each one or just the first one?

When a CDDisc object is to be added to CDDiscDataAccess , what should occur if there is already an object with the same PhysicalID ? Should the current CDDisc object be overwritten or should the new CDDisc object be ignored? In the latter case, should the user be notified of the duplication?

No one solution is correct in all situations. The client and the users ultimately decide how to handle errors. However, for any solution, the user should not have to look inside the code to determine what went wrong. Any message displayed to the user should indicate what was wrong in the file, if anything, and how much of the file was processed if there was a problem.