It is di#cult to write programs that behave correctly in the presence of run-time errors. Existing programming language features often provide poor support for executing clean-up code and for restoring invariants in such exceptional situations. We present a dataflow analysis for finding a certain class of error-handling mistakes: those that arise from a failure to release resources or to clean up properly along all paths. Many real-world programs violate such resource safety policies because of incorrect error handling. Our flow-sensitive analysis keeps track of outstanding obligations along program paths and does a precise modeling of control flow in the presence of exceptions. Using it, we have found over 800 error handling mistakes almost 4 million lines of Java code. The analysis is unsound and produces false positives, but a few simple filtering rules su#ce to remove them in practice. The remaining mistakes were manually verified. These mistakes cause sockets, files and database handles to be leaked along some paths. We present a characterization of the most common causes of those errors and discuss the limitations of exception handling, finalizers and destructors in addressing them. Based on those errors, we propose a programming language feature that keeps track of obligations at run time and ensures that they are discharged. Finally, we present case studies to demonstrate that this feature is natural, e#cient, and can improve reliability; for example, retrofitting a 34kLOC program with it resulted in a 0.5% code size decrease, a surprising 17% speed increase (from correctly deallocating resources in the presence of exceptions) , and more consistent behavior.

The first part of this paper provides rigorous definitions for several basic concepts underlying the design of dependable programs, such as specification, program semantics, exception, program correctness, robustness, failure, fault, and error. The second part investigates what it means to handle exceptions in modular programs structured as hierarchies of data abstractions. The problems to be solved at each abstraction level, such as exception detection and propagation, consistent state recovery and masking are examined in detail. Both programmed exception handling and default exception handling (such as embodied for example in recovery blocks or database transactions) are considered. An assessment of the adequacy of backward recovery in providing tolerance of software design faults is made. An earlier version of this paper was published in "Dependability of Resilient Computers", T. Anderson, Editor, BSP Professional Books, Blackwell Scientific Publications, UK, 1989, pp. 68-97 INTRO...

This paper presents a new model for exception handling, called the replacement model. The replacement model, in contrast to other exception-handling proposals, supports all the handler responses of resumption, termination, retry, and exception propagation, within both statements and expressions, in a modular, simple, and uniform fashion. The model can be embedded in any expression-oriented language and can also be adapted to languages which are not expression oriented with almost all the above advantages. This paper presents the syntactic extensions for embedding the replacement model into Algol 68 and its operational semantics. An axiomatic semantic definition for the model can be found in [271. Categories and Subject Descriptors: D.3.3 [Programming Languages]: Language Constructsabstract

this article differentiate the exception-handling needs of CB-RTS as compared to other software paradigms and can serve as a driving force for future research into exception-handling technology.

It is difficult to write programs that behave correctly in the presence of run-time errors. Proper behavior in the face of exceptional situations is important to the reliability of long-running programs. Existing programming language features often provide poor support for executing clean-up code and for restoring invariants. We present a dataflow analysis for finding a certain class of mistakes made during exceptional situations. We also present a specification miner for automatically inferring partial notions of what programs should be doing. Finally, we propose and evaluate a new language feature, the compensation stack, to make it easier to write solid code in the presence of run-time errors. We give a dataflow analysis for finding a certain class of exception-handling mis-takes: those that arise from a failure to release resources or to clean up properly along all paths. Many real-world programs violate such resource usage rules because of incorrect exception handling. Our flow-sensitive analysis keeps track of outstanding obligations along program paths and does a precise modeling of control flow in the presence of exceptions. Using it, we have found over 800 exception handling mistakes in almost 4 million lines of Java code. The analysis is unsound and produces false positives, but a few simple filtering rules suffice to remove them in practice. The remaining mistakes were manually verified. These mistakes cause sockets, files and database handles to be leaked along some paths. Specifications are necessary in order to find software bugs using program verification tools. We give a novel automatic specification mining algorithm that uses information about exception handling to learn temporal safety rules. Our algorithm is based on the observation that programs often make mistakes along exceptional control-flow paths, even when they behave correctly on normal execution paths. We show that this focus improves the miner’s effectiveness at discovering specifications beneficial for bug finding. We present quantitative results comparing our technique to four existing miners. We highlight assumptions made by various miners that are not always borne out in practice. Additionally, we apply our algorithm to existing Java programs and analyze its ability to learn specifications that find bugs in those programs. In our experiments, we find filtering candidate specifications to be more important than ranking them. We find 430 bugs in 1 million lines of code. Notably, we find 250 more bugs using per-program specifications learned by our algorithm than with generic specifications that apply to all programs. We present a characterization of the most common causes of those bugs and discuss the limitations of exception handling, finalizers and destructors. Based on that characterization we propose a programming language feature, the compensation stack, that keeps track of obligations at run time and ensures that they are discharged. Finally, we present case studies to demonstrate that this feature is natural, efficient, and can improve reliability; for example, retrofitting a 34,000-line program with compensation stacks resulted in a 0.5% code size decrease, a surprising 17% speed increase (from correctly deallocating resources in the presence of exceptions), and more consistent behavior.

Loops with multiple-exits and flags detract from the quality of imperative programs. They tend to make control-structures difficult to understand and, at the same time, introduce the risk of non-termination and other correctness problems. A systematic, generally applicable procedure, called loop rationalization, which removes such features and simplifies loop structures is presented. This method, which is founded on the principle of separation of concerns, is based on strongest postcondition calculations and congruent equivalence transformations. Not only does this method logically simplify loop structures; it also detects a range of defects including a class of non-termination problems and unreachable code. 1.

Loops with multiple-exits and flags detract from the quality of imperative programs. They tend to make control- structures difficult to understand and, at the same time, introduce the risk of non-termination and other correctness problems. A systematic, generally applicable procedure, called loop rationalization which removes such features and simplifies loop structures is presented. This method, which is founded on the principle of separation of concerns is based on strongest postcondition calculations and congruent equivalence transformations. Not only does this method logically simplify loop structures; it also detects a range of defects including non-termination problems and unreachable code.

With programs growing in size and complexity, the quality and cost of developing and maintaining them are still deep concerns to software industries. Dynamically reconfigurable software, which is one paradigm for using component-based software, is a promising approach in reducing the developmental cost while increasing the quality and the reliability. For real-time embedded systems, a dynamically reconfigurable real-time software paradigm provides many major advantages over conventional real-time software development techniques. As with any other real-time software, dynamically reconfigurable software needs exception detection and handling mechanisms to satisfy reliability requirements. How-ever, the focus of developing reusable software has been on the structure of initialization and normal operation code within reusable components. This can make an application composed of reusable software non-deterministic and difficult to understand in the presence of errors. Even if 100 percent of modules are reused, there may still be the need for significant amounts of new code for error handling. Our goal is to create a structured exception handling mechanism for dynamically reconfigurable real-time software (DRRTS) that helps programmers to create reliable