8.8. Dealing with Deviations and Errors

 <  Day Day Up  >  

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.

 <  Day Day Up  >  


Prefactoring
Prefactoring: Extreme Abstraction, Extreme Separation, Extreme Readability
ISBN: 0596008740
EAN: 2147483647
Year: 2005
Pages: 175
Authors: Ken Pugh

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net