HOPL-II The second ACM SIGPLAN conference on History of programming languages
The design and evolution of C++
The design and evolution of C++
Advanced Exception Handling Mechanisms
IEEE Transactions on Software Engineering
Exception handling: issues and a proposed notation
Communications of the ACM
Object-Oriented Software Construction
Object-Oriented Software Construction
Journal of Systems and Software
Practical Common Lisp
Basic Concepts and Taxonomy of Dependable and Secure Computing
IEEE Transactions on Dependable and Secure Computing
IEEE Transactions on Software Engineering
Hi-index | 0.00 |
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. An evaluation approach will be presented.