We present a static analysis that detects potential runtime exceptions that are raised and never handled inside Standard ML(SML) programs. This analysis will predict abrupt termination of SML programs, which is SML's only one "safety hole." Even though SML program's control flow and exception flow are in general mutually dependent, analyzing the two flows are safely decoupled. Program's control-flow is firstly estimated by simple case analysis of call expressions. Using this call-graph information, program's exception flow is derived as set-constraints, whose least model is our analysis result. Both of these two analyses are proven safe and the reasons behind each design decision are discussed. Our implementation of this analysis has been applied to realistic SML programs and shows a promising cost-accuracy performance. For the ML-Lex program, for example, the analysis takes 1.36 seconds and it reports 3 may-uncaught exceptions, which are exactly the exceptions that can really escape. ...

Exception-handling mechanisms in modern programming languages provide a means to help software developers build robust applications by separating the normal control flow of a program from the control flow of the program under exceptional situations. Separating the exceptional structure from the code associated with normal operations bears some consequences. One consequence is that developers wishing to improve the robustness of a program must figure out which exceptions, if any, can flow to a point in the program. Unfortunately, in large programs, this exceptional control flow can be difficult, if not impossible, to determine. In this article, we present a model that encapsulates the minimal concepts necessary for a developer to determine exception flow for object-oriented languages that define exceptions as objects. Using these concepts, we describe why exception-flow information is needed to build and evolve robust programs. We then describe Jex, a static analysis tool we have developed to provide exception-flow information for Java systems based on this model. The Jex tool provides a view of the actual exception types that might arise at different program points and of the handlers that are present. Use of this tool on a collection of Java library and application source code demonstrates that the approach can be helpful to support both local and global improvements to the

It is well known that adding side effects to functional languages changes the operational equivalences of the language. We develop a new language construct, encap, that forces imperative pieces of code to behave purely functionally, i.e., without any visible side effects. The coercion operator encap provides a means of extending the simple reasoning principles for equivalences of code in a functional language to a language with side effects. In earlier work [36], similar coercion operators were developed, but their correctness required the underlying functional language to include parallel operations. The coercion operators developed here are simpler and are proven correct for purely sequential languages. The sequential setting requires the construction of fully abstract models for sequential call-by-value languages and the formulation of a weak form of "monad" suitable for expressing the semantics of call-by-value languages with side effects. 1 Introduction Two pieces of code are...

We present a static analysis that detects potential runtime exceptions that are raised and never handled inside Standard ML (SML) programs. Contrary to our earlier method [Yi94] (based on abstract interpretation [CC77]) where the input program 's control flow is simultaneously computed while our exception analysis progresses, we separate the two phases in a manner similar to conventional data flow analysis. Before the exception analysis begins, we first estimate the input program's control flow from the type information from SML/NJ compiler. Based on this call-graph structure, exception flow is specified as a set of equations, whose solution is computed using an iterative least fixpoint method. At time of this writing, a prototype of this analysis is applied to two realistic SML programs (ML-LEX and OR-SML core) and is 3 or 40 times faster than the earlier method and saves memory by 35 or 65 percent. Key words: program safety, exception handling, high-order exceptions, data flow anal...

Abstract. This paper presents a novel, type-based exception analysis for EC (an Exception Calculus)—a higher-order, typed programming language with first-class, Java-style exceptions. EC exceptions are predeclared and subject to a nominal subtyping relation. Every exception has its own type, and generic exception handling is performed by handling a supertype of all applicable exceptions. Typing is based on result contexts, which are are analogous to the multipleconclusion succedents in Gentzen’s LK. This paper proves the syntactic soundness of EC, and presents a shallow embedding of EC types and judgments in LK. The embedding gives rise to a pleasant interpretation of subtyping as logical consequence. 1