Artur Södler Software-Qualität

Error Handling

Error Handling is an essential part of every application. Of course, now and again something goes wrong. And it is no less self-evident, that software developers cannot imagine all sorts of things that might go awry. That's in the nature of things:

The software developer is responsible for the software to meet certain requirements. Hence, he does not mind about what may go awry. His mind is busy thinking about how everything works well.

We must rethink: The software developer is responsible for the software to avoid damage in any other circumstance. That means as well we have to be informed aubout the cause of a possible problem in order to fix it.

An example: While you close the financial accounting software, the software asks whether the changed accounting data should be saved to disk. You press the "Yes" button. The file does already exist, but in an older version. Just while saving the file, the system detects, that the disk has not enough capacity. Saving the data is interrupted.

In the worst case, the FA data on hard disk is damaged, the software indicates a failure saving the data, but terminates nevertheless.

In the best case, the FA data first of all has been saved using a different file name. Only if there had been enough capacity for the new file, the old one is deleted, and the new one is renamed. Well — before the error message appears, the software tries to delete the incomplete new file. Then it says 1. the disk has not enough capacity, 2. as a consequence the saving of "n:\Management\FinAcc\2014.db" failed, and 3. because of this, the software will not terminate yet.

Error handling is no trivial task. Here are some guidelines:

•		Everything can go wrong. Even while processing an error message, the system can run out of memory; there are not enough resources for an error message window; the successful printout is processed by the printer to accordion paper; the progress bar abends, if an empty data set is being processed.
•		Errors have causes and effect best described as a chain. A single link is often at the same time effect of the previous and cause of the next link. A Consequence is synonymous to a context: The failure to save a configuration file during editing a text is basically different to the failure to save the text. A case study: the Java class Throwable.
•		An error is not always an error. The data record has not been found? Then let us insert it. No reason to bother the user with an error message.
•		Certain errors must be identifiable. The error "no more data records" (see previous example) must be identifiable as a code, not as text. Don't be surprised if the database says "No hay más expedientes."
•		Errors must be identified in order to be ignored. There are only two exceptions: a) The task has been safely completed by other means. b) There is another error message which is more important or more causative.
•		Error information has to be storable. The server is offline? No problem, let us try the backup server. If the backup server also fails, we better present the original (first) error message.
•		A failing subprogram usually leaves no side effects. The half-written file will be deleted. Creating a data record does not leave an empty record. Importing data does never import half of the data. This principle cannot be accomplished without ecxeption. But it simplifies a lot. The user does not have to clean up before the next try.
•		Nothing fails irrevocably, even less after a predefined period of time. The Windows Hardware Wizard "waits" a predetermined time for connected hardware to response. A hardware not responding in time is being ignored. Rethink: Necessary requirements are not yet satisfied — until they are satisfied. A predetermined number of retries or a maximum length of time can only be justified as an implementation of personal experience.
•		Creation of an error information is best supported by an exception. That way we are less tempted to accidentally process invalid data, leading to e.g. "Division by Zero". A Throwable (Java) or similar is either being cast, or it is stored globally, and a dummy value is being thrown. The standard means of all programming langualges are incomplete yet retrofittable.