1 / 10

Run-Time Error Handling

Run-Time Error Handling. Wes Weimer, George Necula. 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

bishops
Download Presentation

Run-Time Error Handling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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!

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

  5. 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!

  6. 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’

  7. 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): • t1 … tn • t1 … tk ck … c1

  8. 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.

  9. 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

More Related