1. A Specification Logic for Exceptions and Beyond Cristina David Cristian Gherghina National University of Singapore

2. Context (Roy Maxion et al. “Improving software robustness with dependability cases”) Exception failures ◦ Up to 2/3 of system crashes ◦ 50% of system security vulnerabilities Need for ◦ Specifying behavior even in the presence of exceptions ◦ Precisely defined yet flexible exception safety guarantees ◦ Tools to enforce such specifications 2

3. Contributions A specification logic for all control flow types An improvement of the classical exception safety guarantees A verification system for a Java-like language 3

4. Specification Logic Current specification logics fail to track control flow types We propose  Explicit tracking of control flow information in the specification logic  An unified view of all control flow types 4

5. Specification Logic An unified view of the control flow: Unify both normal and abnormal control flows Unify both static and dynamic control flows static flow: break, continue, return dynamic flow: try-catch, raise 5

6. Unified control flow hierarchy static dynamic 6 dynamic control flows due to exceptions static control flows normal execution can be caught cannot be caught

7. Specification Logic The specification formulae are enriched separation logic formulae They allow for capturing the states for both normal and exceptional executions 7

8. Specification Formulae ◦ ¯ captures constraints on flow variables ◦ ¿ captures the current flow ◦ Current flow values can be:  Exact flow types  Subtypes and type differences 8

9. Exception Safety Guarantees (Stroustrup: Exception Safety: Concepts and Techniques) ◦ No-leak guarantee  Exceptions leave the operands in well-defined states  Every acquired resources is released ◦ Basic guarantee  The class invariants are always maintained  Very forgiving with the programmer ◦ Relaxed strong guarantee  Precise explicit effect  Currently, difficult to specify ◦ Strong guarantee ◦ The operation either succeeds or has no effect if an exception is raised ◦ More difficult to implement ◦ No throw guarantee ◦ Never throw an exception 9

10. No Throw Guarantee E.g. a swap function The postcondition specifies that no exceptional flow can escape the swap method 10

11. Strong Guarantee An operation leaves its operands in well-defined states ensures that every acquired resource is released class invariants are maintained succeeds, or has no effects when an exception occurs 11

12. Relaxed Strong Guarantee An operation leaves its operands in well-defined states ensures that every acquired resource is released eventually class invariants are maintained succeeds, or has a precisely known effect when an exception occurs 12

13. Verification System Translates Source Language programs into Core Language programs ◦ (C. David et al. ”Translation and optimization for a core calculus with exceptions” PEPM09) Performs forward verification by computing the strongest post condition Proven to be sound 13

14. Source Language SrcLang Supports constructs challenging from the point of how control flow is transferred finally construct multi-return function call try catch with multiple handlers break and continue statements 14

15. Core Language As small as a corresponding one without exceptions Supports the translation of challenging constructs from the source language Easier to analyze than the source language 15

16. Source Lang Core Lang 16 …

17. Important constructs of the Core Lang Flow and value: ft#v normal flow: norm#v exceptional flow: ty(v)#v Try-catch construct: try e 1 catch((c@fv)#v) e 2 captures both exceptional and normal control flow 17 control flow variable capturing the control flow type (fv<:c) the thrown value

18. Verification Example 18 try { if (x>0) compute(x,p) else ret#p }catch(over_exc@fv#v) brk_l#()

19. Verification Example if (x>0) compute(x,p); else ret#p {true & flow=norm} {x>0 & flow=norm} {x≤0 & flow = norm} {(x>0 & x’=x-1& p’=p*x & flow=norm) Ç (res::num_exc() & x>0 & p=0 & flow=num_exc)} {x≤0 & res=p & flow = ret} { (x≤0 & res=p & flow = ret) Ç (x>0 & x’=x-1& p’=p*x & flow=norm) Ç (res::num_exc() & x>0 & p=0 & flow=num_exc)} 19

20. Verification Example try{ … }catch(over_exc@fv#v) brk_l#() {true & flow=norm} {v::over_exc() & x>0 & p=0 & flow=norm & fv=over_exc} {v::over_exc() & x>0 & p=0 & flow=brk_l & fv=over_exc} {(x≤0 & res=p & flow = ret) Ç (x>0 & x’=x-1& p’=p*x & flow=norm) 9 v,fv ¢ (x>0 & res=3 & v=x& flow=exception & fv=exception)} 20 { (x≤0 & res=p & flow = ret) Ç (x>0 & x’=x-1& p’=p*x & flow=norm) Ç (res::num_exc() & x>0 & p=0 & flow=num_exc)} over_exc <: num_exc

21. Verification Example try{ … }catch(over_exc@fv#v) … {v::over_exc() & x>0 & p=0 & flow=brk_l & fv=over_exc} {(x≤0 & res=p & flow = ret) Ç (x>0 & x’=x-1& p’=p*x & flow=norm) Ç 9 v,fv ¢ (v::over_exc() & x>0 & p=0 & flow=brk_l & fv=over_exc) Ç (res::num_exc() & x>0 & p=0 & flow=num_exc – over_exc)} 21 { (x≤0 & res=p & flow = ret) Ç (x>0 & x’=x-1& p’=p*x & flow=norm) Ç (res::num_exc() & x>0 & p=0 & flow=num_exc)} over_exc <: num_exc

22. Try-catch and “#” Verification Rules 22 the “caught” states the “uncaught” states

23. Experimental Results Successfully verified test examples from: ◦ KeY project, exercising specific features ◦ SPEC benchmarks, broad range exception handling 23

24. Related Work SPEC# ◦ K. Rustan et al. “Exception safety for C#” KEY project ◦ B. Beckert et al. “Verification of Object- Oriented Software: The KeY Approach” Type systems ◦ M. Blume et al. “Exception handlers as extensible cases” CSP 24

25. Thank you! 25

26. Multi-return function call 26 Explicitly captures the choice of the return point, based on the control flow caught after the evaluation