DOCSLIB.ORG

Contract-Based Testing for PHP with Praspel

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Contract-Based Testing for PHP with Praspel ARTICLE IN PRESS JID: JSS [m5G; June 16, 2017;14:57 ] The Journal of Systems and Software 0 0 0 (2017) 1–14 Contents lists available at ScienceDirect The Journal of Systems and Software journal homepage: www.elsevier.com/locate/jss Contract-based testing for PHP with Praspel ∗ Frederic Dadeau a, , Alain Giorgetti a, Fabrice Bouquet a, Ivan Enderlin b a FEMTO-ST Institute, Univ. Bourgogne Franche-Comté, CNRS, Besançon, France b Liip.ch, rue Etraz 4, Lausanne, Switzerland a r t i c l e i n f o a b s t r a c t Article history: We summarize several contributions related to the PHP Realistic Annotation and SPEcification Language Received 21 July 2016 (Praspel). This language extends PHP programs with annotations for the formal specification of the be- Revised 19 May 2017 havior of their functions and for the declaration of types for their data. These contracts are used to au- Accepted 8 June 2017 tomate test generation, by deriving test cases and test data, and test execution, by checking assertions Available online xxx at run-time in order to establish the test verdict. Our approach to contract-based testing for PHP is fully Keywords: implemented into a PHP framework currently in use by several web companies. PHP ©2017 Published by Elsevier Inc. Design by Contract Annotations Test generation 1. Introduction from the model) into executable test scripts (using the API pro- vided by the SUT and the concrete data on which it operates). Each Model-Based Testing (MBT for short) ( Beizer, 1995 ) is a tech- evolution of the API or model can also impact this concretization nique in which a model of the System Under Test (SUT) is em- step. ployed in order to validate it by using tests. In this context, the Annotation languages provide an interesting solution to address model can be of two uses. First, it can be used to compute the these issues. Their underlying paradigm consists of inserting the test cases by providing an exploitable abstraction of the SUT from model as annotations (i.e. comments) in the code, expressing for- which test data or even test sequences can be computed. Second, mal assertions about it, namely: (i ) invariants , which are properties the model can provide the test oracle, namely the expected result that should hold at each execution step, and (ii ) pre- and postcon- against which the execution of the SUT is compared. MBT makes ditions , which are conditions that respectively have to hold for a it possible to automate the test generation, and, with an appropri- method to be invoked and after its execution. These assertions es- ate concretization layer, the test execution and verdict assignment tablish a contract between code developers and their users. There- phases. It is implemented in many tools, based on various model- fore, behavioral interface specification languages for these annota- ing languages or notations ( Utting et al., 2012 ). tions are also called contract languages. Design by Contract (DbC for Although MBT is a good way to promote formal methods among short) ( Meyer, 1992 ) was first introduced by B. Meyer with the Eif- developers, its application is often restricted to critical and/or em- fel language ( Meyer, 1987 ). Various contract languages extend pop- bedded software that requires a strong level of validation ( Zander ular programming languages, such as JML for Java ( Leavens et al., et al., 2011 ). Three main causes can be identified. First, the de- 1999 ) or ACSL for C ( Baudin et al., 2013 ). Annotation-based DbC is sign of the formal model represents an additional cost, sometimes thus a way to introduce lightweight formal methods in the process much higher than the manual validation cost. Second, the model of development of an application, and the syntactic proximity be- design is a complex task that requires modeling skills and under- tween the code and its model makes its writing easier to learn and standing of formal methods, thus requiring skilled validation en- to practice by developers, even if they are not familiar with formal gineers to be put into practice. Finally, the production of the test methods. scripts adds the additional effort and cost of the test concretiza- One of the main interests and uses of contracts is for testing. In- tion. Since the model is an abstraction of the SUT, a test concretiza- deed, Contract-Based Testing (CBT for short) ( Aichernig, 2003 ) has tion layer is required to translate abstract test cases (computed been introduced to exploit annotation languages for program test- ing: ∗ Corresponding author. E-mail addresses: [email protected] , [email protected]. (i) The information contained in invariants and preconditions fr (F. Dadeau). can be used to generate test cases. http://dx.doi.org/10.1016/j.jss.2017.06.017 0164-1212/© 2017 Published by Elsevier Inc. Please cite this article as: F. Dadeau et al., Contract-based testing for PHP with Praspel, The Journal of Systems and Software (2017), http://dx.doi.org/10.1016/j.jss.2017.06.017 ARTICLE IN PRESS JID: JSS [m5G; June 16, 2017;14:57 ] 2 F. Dadeau et al. / The Journal of Systems and Software 0 0 0 (2017) 1–14 (ii) Postconditions provide a test oracle for free , by assertion checking at run-time: the test succeeds if no assertion is vi- olated, and fails otherwise. (iii) Due to the proximity between the code and the model, there is no abstraction gap to bridge, contrary to other MBT approaches which require concretization of the ab- stract test cases, and establish the test verdict on the implementation. We present a contract-based testing approach for PHP, which has been fully integrated in a tool-set and made available to the PHP community. This approach uses Praspel, a specification lan- guage for PHP ( Enderlin et al., 2011 ) that relies on realistic domains . These domains make it possible to assign a domain of values to data appearing either as class attributes or method parameters. Realistic domains present two useful features for testing: predica- bility , which is the possibility to check whether a datum belongs to its associated domain, and samplability , which is the possibil- ity to automatically generate a datum from a realistic domain. A standard library of predefined realistic domains (mainly scalar do- mains, strings and arrays) is available along with an integrated test environment. Our approach aims at automating test generation, test execution Fig. 1. Praspel contract clauses. and test verdict assignment, especially in the domain of web appli- cations. Automated test generation is guided by a dedicated set of coverage criteria. They are based on the contracts’ structure, in or- der to activate the behaviors described by the contract. Test data are produced by various effective data generators, dedicated to the kinds of data most frequently used in web applications. Finally, test verdict assignment is ensured by an automated runtime assertion , ∗, checking mechanism that is used to detect non-conformances be- by s. r can be ? + or respectively for 0 or 1 time, 1 or more tween the code and the specification. times and 0 or more times. If s is not empty, then s must be a This article focuses on the following contributions: token. The rules for attribute-clauses and method-clauses in Fig. 1 re- • The definition of test selection criteria, that can be used either spectively define clauses annotating a class and a method. (The to generate test cases, even parameterized test cases, or to as- syntactic entity method-clauses shows the order of clauses in nor- sess the relevance of a test suite, mal form, but the actual Praspel grammar accepts clauses in • The use of contracts as a test oracle, and any order.) Invariants, behaviors, preconditions, normal and ex- • An experiment with independent software testing engineers, to ceptional postconditions are respectively declared by the key- identify the benefits of contract-based testing versus manual word @invariant , @behavior , @requires , @ensures and testing. @throwable . The syntax and semantics of these clauses are stan- This article is organized as follows. Section 2 introduces the dard (see Enderlin et al., 2011 for details and short examples). We syntax and semantics of contracts in Praspel, to specify class in- emphasize here only those language features added to the version variants and method behaviors. Section 3 presents the contract- of Praspel presented in Enderlin et al. (2011) . The first two are the based testing approach we propose, based on contract coverage @description clause to write an informal description of a be- criteria, and the runtime assertion checking used to provide the havior, and the @default behavior, whose implicit precondition test oracle and automatically assign a test verdict. Experimental is the conjunction of negations of all other behavior preconditions. results of real-world usage of Praspel are reported in Section 4 . Fig. 2 describes the syntax of Praspel expressions. They are Section 5 presents related work. Finally, Section 6 concludes and composed of declarations, predicates, and array conditions, respec- presents some future work. tively detailed in Sections 2.2, 2.3 and 2.5 . The simplest declaration is of the form v : r, where v is a variable and r is a realistic domain , 2. Praspel contracts a key notion for testing summarized in Section 2.1 and exemplified in Section 2.4 . This section summarizes the syntax and semantics of Praspel Fig. 3 shows the running example of a contract on a method ( PHP Realistic Annotation and SPEcification Language ). that manipulates an IRC stream. The method compute has two As an annotation language, Praspel is written in the source code arguments: server which is a class of kind \ Irc \ Server , and of the software, more precisely in PHP comments.
Load more

Recommended publications
  • Génération Automatique De Tests Unitaires Avec Praspel, Un Langage De Spécification Pour PHP the Art of Contract-Based Testing in PHP with Praspel
    CORE Metadata, citation and similar papers at core.ac.uk Provided by HAL - Université de Franche-Comté G´en´erationautomatique de tests unitaires avec Praspel, un langage de sp´ecificationpour PHP Ivan Enderlin To cite this version: Ivan Enderlin. G´en´eration automatique de tests unitaires avec Praspel, un langage de sp´ecificationpour PHP. Informatique et langage [cs.CL]. Universit´ede Franche-Comt´e,2014. Fran¸cais. <NNT : 2014BESA2067>. <tel-01093355v2> HAL Id: tel-01093355 https://hal.inria.fr/tel-01093355v2 Submitted on 19 Oct 2016 HAL is a multi-disciplinary open access L'archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destin´eeau d´ep^otet `ala diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publi´esou non, lished or not. The documents may come from ´emanant des ´etablissements d'enseignement et de teaching and research institutions in France or recherche fran¸caisou ´etrangers,des laboratoires abroad, or from public or private research centers. publics ou priv´es. Thèse de Doctorat école doctorale sciences pour l’ingénieur et microtechniques UNIVERSITÉ DE FRANCHE-COMTÉ No X X X THÈSE présentée par Ivan Enderlin pour obtenir le Grade de Docteur de l’Université de Franche-Comté K 8 k Génération automatique de tests unitaires avec Praspel, un langage de spécification pour PHP The Art of Contract-based Testing in PHP with Praspel Spécialité Informatique Instituts Femto-ST (département DISC) et INRIA (laboratoire LORIA) Soutenue publiquement
    [Show full text]
  • Assertions, Pre/Post- Conditions and Invariants
    9/14/12 Assertions, pre/post- conditions and invariants Section 2.1 in Walls and Mirrors Section 4.5 Rosen Programming as a contract n Specifying what each method does q Specify it in a comment before method's header n Precondition q What is assumed to be true before the method is executed q Caller obligation n Postcondition q Specifies what will happen if the preconditions are met q Method obligation 1 9/14/12 Class Invariants n A class invariant is a condition that all objects of that class must satisfy while it can be observed by clients n What about Points in Cloud? q boundaries? q center? What is an assertion? n An assertion is a statement that says something about the state of your program n Should be true if there are no mistakes in the program //n == 1 while (n < limit) { n = 2 * n; } // what could you state here? 2 9/14/12 What is an assertion? n An assertion is a statement that says something about the state of your program n Should be true if there are no mistakes in the program //n == 1 while (n < limit) { n = 2 * n; } //n >= limit //more? What is an assertion? n An assertion is a statement that says something about the state of your program n Should be true if there are no mistakes in the program //n == 1 while (n < limit) { n = 2 * n; } //n >= limit //n is the smallest power of 2 >= limit 3 9/14/12 assert Using assert: assert n == 1; while (n < limit) { n = 2 * n; } assert n >= limit; When to use Assertions n We can use assertions to guarantee the behavior.
    [Show full text]
  • Grammar-Based Testing Using Realistic Domains in PHP Ivan Enderlin, Frédéric Dadeau, Alain Giorgetti, Fabrice Bouquet
    Grammar-Based Testing using Realistic Domains in PHP Ivan Enderlin, Frédéric Dadeau, Alain Giorgetti, Fabrice Bouquet To cite this version: Ivan Enderlin, Frédéric Dadeau, Alain Giorgetti, Fabrice Bouquet. Grammar-Based Testing using Realistic Domains in PHP. A-MOST 2012, 8th Workshop on Advances in Model Based Testing, joint to the ICST’12 IEEE Int. Conf. on Software Testing, Verification and Validation, Jan 2012, Canada. pp.509–518. hal-00931662 HAL Id: hal-00931662 https://hal.archives-ouvertes.fr/hal-00931662 Submitted on 16 Jan 2014 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Grammar-Based Testing using Realistic Domains in PHP Ivan Enderlin, Fred´ eric´ Dadeau, Alain Giorgetti and Fabrice Bouquet Institut FEMTO-ST UMR CNRS 6174 - University of Franche-Comte´ - INRIA CASSIS Project 16 route de Gray - 25030 Besanc¸on cedex, France Email: fivan.enderlin,frederic.dadeau,alain.giorgetti,[email protected] Abstract—This paper presents an integration of grammar- Contract-based testing [5] has been introduced in part to based testing in a framework for contract-based testing in PHP. address these limitations. It is based on the notion of Design It relies on the notion of realistic domains, that make it possible by Contract (DbC) [6] introduced by Meyer with Eiffel [7].
    [Show full text]
  • Design by Contract: the Lessons of Ariane
    . Editor: Bertrand Meyer, EiffelSoft, 270 Storke Rd., Ste. 7, Goleta, CA 93117; voice (805) 685-6869; [email protected] several hours (at least in earlier versions of Ariane), it was better to let the computa- tion proceed than to stop it and then have Design by to restart it if liftoff was delayed. So the SRI computation continues for 50 seconds after the start of flight mode—well into the flight period. After takeoff, of course, this com- Contract: putation is useless. In the Ariane 5 flight, Object Technology however, it caused an exception, which was not caught and—boom. The exception was due to a floating- point error during a conversion from a 64- The Lessons bit floating-point value, representing the flight’s “horizontal bias,” to a 16-bit signed integer: In other words, the value that was converted was greater than what of Ariane can be represented as a 16-bit signed inte- ger. There was no explicit exception han- dler to catch the exception, so it followed the usual fate of uncaught exceptions and crashed the entire software, hence the onboard computers, hence the mission. This is the kind of trivial error that we Jean-Marc Jézéquel, IRISA/CNRS are all familiar with (raise your hand if you Bertrand Meyer, EiffelSoft have never done anything of this sort), although fortunately the consequences are usually less expensive. How in the world everal contributions to this made up of respected experts from major department have emphasized the European countries, which produced a How in the world could importance of design by contract report in hardly more than a month.
    [Show full text]
  • Contracts for Concurrency Piotr Nienaltowski, Bertrand Meyer, Jonathan S
    Contracts for concurrency Piotr Nienaltowski, Bertrand Meyer, Jonathan S. Ostroff To cite this version: Piotr Nienaltowski, Bertrand Meyer, Jonathan S. Ostroff. Contracts for concurrency. Formal Aspects of Computing, Springer Verlag, 2008, 21 (4), pp.305-318. 10.1007/s00165-007-0063-2. hal-00477897 HAL Id: hal-00477897 https://hal.archives-ouvertes.fr/hal-00477897 Submitted on 30 Apr 2010 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. DOI 10.1007/s00165-007-0063-2 BCS © 2007 Formal Aspects Formal Aspects of Computing (2009) 21: 305–318 of Computing Contracts for concurrency Piotr Nienaltowski1, Bertrand Meyer2 and Jonathan S. Ostroff3 1 Praxis High Integrity Systems Limited, 20 Manvers Street, Bath BA1 1PX, UK E-mail: [email protected] 2 ETH Zurich, Zurich, Switzerland 3 York University, Toronto, Canada Abstract. The SCOOP model extends the Eiffel programming language to provide support for concurrent programming. The model is based on the principles of Design by Contract. The semantics of contracts used in the original proposal (SCOOP 97) is not suitable for concurrent programming because it restricts parallelism and complicates reasoning about program correctness. This article outlines a new contract semantics which applies equally well in concurrent and sequential contexts and permits a flexible use of contracts for specifying the mutual rights and obligations of clients and suppliers while preserving the potential for parallelism.
    [Show full text]
  • Implementing Closures in Dafny Research Project Report
    Implementing Closures in Dafny Research Project Report • Author: Alexandru Dima 1 • Total number of pages: 22 • Date: Tuesday 28th September, 2010 • Location: Z¨urich, Switzerland 1E-mail: [email protected] Contents 1 Introduction 1 2 Background 1 2.1 Closures . .1 2.2 Dafny . .2 3 General approach 3 4 Procedural Closures 5 4.1 Procedural Closure Type . .5 4.2 Procedural Closure Specifications . .6 4.3 A basic procedural closure example . .6 4.3.1 Discussion . .6 4.3.2 Boogie output . .8 4.4 A counter factory example . 13 4.5 Delegation example . 17 5 Pure Closures 18 5.1 Pure Closure Type . 18 5.2 A recursive while . 19 6 Conclusions 21 6.1 Limitations . 21 6.2 Possible extensions . 21 6.3 Acknowledgments . 21 2 BACKGROUND 1 Introduction Closures represent a particularly useful language feature. They provide a means to keep the functionality linked together with state, providing a source of ex- pressiveness, conciseness and, when used correctly, give programmers a sense of freedom that few other language features do. Smalltalk's standard control structures, including branches (if/then/else) and loops (while and for) are very good examples of using closures, as closures de- lay evaluation; the state they capture may be used as a private communication channel between multiple closures closed over the same environment; closures may be used for handling User Interface events; the possibilities are endless. Although they have been used for decades, static verification has not yet tack- led the problems which appear when trying to reason modularly about closures.
    [Show full text]
  • Study on Eiffel
    Study on Eiffel Jie Yao Anurag Katiyar May 11, 2008 Abstract This report gives an introduction to Eiffel, an object oriented language. The objective of the report is to draw the attention of the reader to the salient features of Eiffel. The report explains some of these features in brief along with language syntax. The report includes some code snippets that were written in the process of learning Eiffel. Some of the more detailed tutorials, books and papers on Eiffel can be found at www.eiffel.com 1 Contents 1 Introduction 3 2 Eiffel Constructs and Grammar 3 2.1 ”Hello World” . 3 2.2 Data Types . 3 2.3 Classes . 3 2.4 Libraries . 4 2.5 Features . 4 2.6 Class relations and hierarchy . 4 2.7 Inheritance . 4 2.8 Genericity . 5 2.9 Object Creation . 5 2.10 Exceptions . 6 2.11 Agents and Iteration . 6 2.12 Tuples . 6 2.13 Typing . 6 2.14 Scope . 7 2.15 Memory Management . 7 2.16 External software . 7 3 Fundamental Properties 7 3.1 ”Has” Properties . 8 3.2 ”Has no” Properties . 9 4 Design principles in Eiffel 10 4.1 Design by Contract . 10 4.2 Command Query Separation . 11 4.3 Uniform Access Principle . 11 4.4 Single Choice Principle . 11 5 Compilation Process in Eiffel 11 6 Exception Handling in the compiler 12 7 Garbage Collection for Eiffel 12 7.1 Garbage Collector Structure . 12 7.2 Garbage Collector in Action . 13 8 Eiffel’s approach to typing 13 8.1 Multiple inheritance .
    [Show full text]
  • Verification of Object Oriented Programs Using Class Invariants
    Verification of Object Oriented Programs Using Class Invariants Kees Huizing and Ruurd Kuiper and SOOP?? Eindhoven University of Technology, PO Box 513, 5600 MB Eindhoven, The Netherlands, [email protected], [email protected] Abstract A proof system is presented for the verification and derivation of object oriented pro- grams with as main features strong typing, dynamic binding, and inheritance. The proof system is inspired on Meyer’s system of class invariants [12] and remedies its unsound- ness, which is already recognized by Meyer. Dynamic binding is treated in a flexible way: when throughout the class hierarchy overriding methods respect the pre- and post- conditions of the overridden methods, very simple proof rules for method calls suffice; more powerful proof rules are supplied for cases where one cannot or does not want to follow this restriction. The proof system is complete relative to proofs for properties of pointers and the data domain. 1 Introduction Although formal verification is not very common in the discipline of object oriented programming, the importance of formal specification is generally ac- knowledged ([12]). With the increased interest in component based develop- ment, it becomes even more important that components are specified in an un- ambiguous manner, since users or buyers of components often have no other knowledge about a component than its specification and at the same time rely heavily on its correct functioning in their framework. The specification of a class, sometimes called contract, usually contains at least pre- and postcondi- tions for the public mehtods and a class invariant. A class invariant expresses which states of the objects of the class are consis- tent, or “legal”.
    [Show full text]
  • You Say 'JML' ? Wikipedia (En)
    You say 'JML' ? Wikipedia (en) PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Mon, 06 Jan 2014 09:58:42 UTC Contents Articles Java Modeling Language 1 Design by contract 5 Formal methods 10 References Article Sources and Contributors 15 Image Sources, Licenses and Contributors 16 Article Licenses License 17 Java Modeling Language 1 Java Modeling Language The Java Modeling Language (JML) is a specification language for Java programs, using Hoare style pre- and postconditions and invariants, that follows the design by contract paradigm. Specifications are written as Java annotation comments to the source files, which hence can be compiled with any Java compiler. Various verification tools, such as a runtime assertion checker and the Extended Static Checker (ESC/Java) aid development. Overview JML is a behavioural interface specification language for Java modules. JML provides semantics to formally describe the behavior of a Java module, preventing ambiguity with regard to the module designers' intentions. JML inherits ideas from Eiffel, Larch and the Refinement Calculus, with the goal of providing rigorous formal semantics while still being accessible to any Java programmer. Various tools are available that make use of JML's behavioral specifications. Because specifications can be written as annotations in Java program files, or stored in separate specification files, Java modules with JML specifications can be compiled unchanged with any Java compiler. Syntax JML specifications are added to Java code in the form of annotations in comments. Java comments are interpreted as JML annotations when they begin with an @ sign.
    [Show full text]
  • Precondition Enforcement Analysis for Quality Assurance
    Precondition Enforcement Analysis for Quality Assurance Nadja Beeli Submitted to the degree of Master of Science ETH in Computer Science Supervised by Prof. Dr. Bertrand Meyer and Dr. Karine Arnout April - October 2004 Abstract The crash of Ariane 5 dramatically showed the importance of correctness in software and that the goal to produce reliable software has not yet been achieved. Therefore, this master thesis targets the development of a static analysis, which ensures preconditions and thus enhances a sound reuse of software. As a result, we could determine many preconditions to be fulfilled, especially preconditions of a certain class, which are used most often. This confirms that static analysis is justified in a development process of quality software. Acknowledgements I would like to deeply thank Dr. Karine Arnout for her support and explanations on the subject of the thesis, and her prompt answers. Furthermore I thank Prof. Dr. Bertrand Meyer, who gave me the opportunity to accomplish my master thesis in the field of Design by Contract, and for his introduction on the static analysis of preconditions. A special thank goes to Éric Bezault, who introduced me to GOBO Eiffel, and swiftly answered my questions. 2 Table of Contents Chapter 1 - Concept of Contracts ........................................................................................6 1.1. The Crash of Ariane 5.............................................................................................6 1.2. Design by Contract in Context of Ariane 5..............................................................6
    [Show full text]
  • VERIFICATION of OBJECT-ORIENTED PROGRAMS with INVARIANTS at Least to Hoare’S 1972 Paper on Data-Representation Correctness [19]
    Vol. 3, No. 6 Special issue: ECOOP 2003 workshop on FTfJP Verification of object-oriented programs with invariants Mike Barnett, Robert DeLine, Manuel Fahndrich¨ , K. Rustan M. Leino, Wolfram Schulte Microsoft Research, Redmond, WA, USA An object invariant defines what it means for an object’s data to be in a consis- tent state. Object invariants are central to the design and correctness of object- oriented programs. This paper defines a programming methodology for using object invariants. The methodology, which enriches a program’s state space to express when each object invariant holds, deals with owned object components, ownership transfer, and subclassing, and is expressive enough to allow many interesting object-oriented programs to be specified and verified. Lending itself to sound modular verification, the methodology also provides a solution to the problem of determining what state a method is allowed to modify. 1 INTRODUCTION Writing and maintaining software is difficult and error prone, in part because it requires coping with many details. Mechanical programming tools can relieve some of this bur- den. For example, an important and pervasive tool is the type checker, which allows the programmer to describe in broad-brush terms the set of values each program vari- able can take. Using these descriptions, the type checker mechanically checks all reads and writes of program variables to ensure that no variable takes on a forbidden value. The type checker is usually built into the compiler, which also checks other details. For example, the compiler may check that every variable use is preceded by an assignment, that any read-only variable is not changed after its initial assignment, or that variables declared in certain scopes or with certain access modifiers are not referenced from inap- propriate places.
    [Show full text]
  • Failboxes: Provably Safe Exception Handling*
    Failboxes: Provably Safe Exception Handling? Bart Jacobs?? and Frank Piessens Department of Computer Science, Katholieke Universiteit Leuven, Belgium fbart.jacobs,[email protected] Abstract. The primary goal of exception mechanisms is to help ensure that when an operation fails, code that depends on the operation's suc- cessful completion is not executed (a property we call dependency safety). However, the exception mechanisms of current mainstream programming languages make it hard to achieve dependency safety, in particular when objects manipulated inside a try block outlive the try block. Many programming languages, mechanisms and paradigms have been proposed that address this issue. However, they all depart significantly from current practice. In this paper, we propose a language mechanism called failboxes. When applied correctly, failboxes have no significant im- pact on the structure, the semantics, or the performance of the program, other than to eliminate the executions that violate dependency safety. Specifically, programmers may create failboxes dynamically and execute blocks of code in them. Once any such block fails, all subsequent at- tempts to execute code in the failbox will fail. To achieve dependency safety, programmers simply need to ensure that if an operation B de- pends on an operation A, then A and B are executed in the same failbox. Furthermore, failboxes help fix the unsafe interaction between locks and exceptions and they enable safe cancellation and robust resource cleanup. Finally, the Fail Fast mechanism prevents liveness issues when a thread is waiting on a failed thread. We give a formal syntax and semantics of the new constructs, and prove dependency safety.
    [Show full text]