1. Run-Time Error Handling Wes Weimer, George Necula

2. Motivation ► Static Safety Analyses:  Good  Often Incomplete  Or program may actually have bugs ► Could ask the programmers …  Fix it, annotate it, tell us if it is a bug, etc.  Not always feasible  Loops, heap data structures, preconditions, etc.

3. Add Run-Time Checks ► CCured, virtual memory hardware ► Perl’s Taint Analysis ► Java downcasts ► SLAM / BLAST  Use predicates to instrument error paths ► Now nothing can possibly go wrong!

5. When Good Checks Go Bad ► Most common * Java exception handler: catch (Exception e) { catch (Exception e) {e.printStackTrace(System.err);System.exit(-1); } ► Second most common: catch (Exception e) { ; } catch (Exception e) { ; } ► Can we do more than Abort or Ignore?

6. Why So Abysmal? ► Ironclad error-handling is  Repetitive – no way to set generic policies  Path- and flow-sensitive  Distant – handling separate from normal code  Complicated by exceptions ► Programs have errors in their error-handling ► Let’s add language support!

7. Plan ► Annotate interfaces and actions with  Compensations  Obligations  Things-to-be-done-before-leaving  Ways to restore invariants ► Keep dynamic stacks of these at run-time  As first-class citizens ► Like ‘sagas’ or ‘compensating xactions’

8. Guarantees ► Strong static type system + run-time checks ► Obligations cannot be ignored ► Dynamic extents (e.g., loops) handled ► Nesting, passing obligations, etc. ► Can enforce (but is more general than):  t 1 … t n  t 1 … t k c k … c 1

9. Why not use … ► Transactions, failure transparency, discount checking, system-level undo, linear type systems, regions, guide, purely static methods, more general exceptions, workflow, flowmark, Barbara Liskov, vino, …  All are imperfect fits for this area.

10. Conclusion ► Many sources of run-time errors in code  And we’re adding new ones with CCured, etc. ► Run-time is only “too late” if unhandled ► What to do when a run-time error occurs? ► Difficult to specify! ► Let’s make it easier to code up. ► Future: automatic inference  For standard libraries and interfaces