Extended exceptions for contingencies and their implications for the engineering process

We observed a general problem of sequential programs, which often results in design and programming errors in industrial software engineering projects, and propose a solution approach. Telephone lines may be busy, banking accounts may be overdrawn and disks may be full. These things happen in the real world, causing the disruption and non-fulfillment of an expected service. Ignoring these problems leads to violations of the postconditions of the caller that depends on the service. The conditions are exactly known and cannot always be avoided, but measures could be taken afterwards. A good program should handle them as part of the specification. As such they are not specification violations and should not be regarded as errors. Unfortunately, they usually can or shall not be handled immediately within the direct caller, e.g., for information hiding reasons. The problem is similar to the problem of error code handling and handling them with exception mechanisms seems reasonable, but the problem is even more complex. These situations must not terminate the system suddenly, because that also violates postconditions. Consequently, exceptions for these situations must be distinguished from exceptions for errors and are worth handling separately. Therefore, we introduce the new concept contingency for such situations. Since the conditions are defined, they are candidates for forward recovery, but conventional exception mechanisms are not appropriate for that purpose. Appropriate mechanisms are presented in this paper. A systematic inspection and handling of contingencies with these mechanisms before runtime can diagnose and avoid subsets of specification violations effectively. This implies some consequences for the engineering process.