|< Day Day Up >|
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
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
, which in
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
class, which is an unchecked exception. An unchecked exception does not have to be indicated in the
clause for a method. A method throws
when an error occurs of such severity that the program should not continue. The exception represents
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
|< Day Day Up >|