Run-Time Error Handling

Run-Time Error HandlingRun-Time Error Handling

Wes Weimer, George NeculaWes Weimer, George Necula

MotivationMotivation

►Static Safety Analyses:►Static Safety Analyses:

GoodGood

Often IncompleteOften Incomplete

Or program may actually have bugsOr program may actually have bugs

►Could ask the programmers …►Could ask the programmers …

Fix it, annotate it, tell us if it is a bug, etc.Fix it, annotate it, tell us if it is a bug, etc.

Not always feasibleNot always feasible

Loops, heap data structures, preconditions, etc.Loops, heap data structures, preconditions, etc.

Add Run-Time ChecksAdd Run-Time Checks

►CCured, virtual memory hardware►CCured, virtual memory hardware

►Perl’s Taint Analysis►Perl’s Taint Analysis

►Java downcasts►Java downcasts

►SLAM / BLAST►SLAM / BLAST

Use predicates to instrument error pathsUse predicates to instrument error paths

►Now nothing can possibly go wrong!►Now nothing can possibly go wrong!

When Good Checks Go BadWhen Good Checks Go Bad

►Most common* Java exception handler:►Most common* Java exception handler:

catch (Exception e) { catch (Exception e) {

e.printStackTrace(System.err);e.printStackTrace(System.err);

System.exit(-1);System.exit(-1);

} }

►Second most common:►Second most common:

catch (Exception e) { ; } catch (Exception e) { ; }

►Can we do more than Abort or Ignore?►Can we do more than Abort or Ignore?

Why So Abysmal?Why So Abysmal?

►Ironclad error-handling is►Ironclad error-handling is

Repetitive – no way to set generic policiesRepetitive – no way to set generic policies

Path- and flow-sensitivePath- and flow-sensitive

Distant – handling separate from normal codeDistant – handling separate from normal code

Complicated by exceptionsComplicated by exceptions

►Programs have errors in their error-handling►Programs have errors in their error-handling

►Let’s add language support!►Let’s add language support!

PlanPlan

►Annotate interfaces and actions with►Annotate interfaces and actions with

CompensationsCompensations

ObligationsObligations

Things-to-be-done-before-leavingThings-to-be-done-before-leaving

Ways to restore invariantsWays to restore invariants

►Keep dynamic stacks of these at run-time►Keep dynamic stacks of these at run-time

As first-class citizensAs first-class citizens

►Like ‘sagas’ or ‘compensating xactions’►Like ‘sagas’ or ‘compensating xactions’

GuaranteesGuarantees

►Strong static type system + run-time checks►Strong static type system + run-time checks

►Obligations cannot be ignored►Obligations cannot be ignored

►Dynamic extents (e.g., loops) handled►Dynamic extents (e.g., loops) handled

►Nesting, passing obligations, etc.►Nesting, passing obligations, etc.

►Can enforce (but is more general than):►Can enforce (but is more general than):

t1 … tnt1 … tn

t1 … tk ck … c1t1 … tk ck … c1

Why not use …Why not use …

►Transactions, failure transparency, discountchecking, system-level undo, linear typesystems, regions, guide, purely staticmethods, more general exceptions,workflow, flowmark, Barbara Liskov, vino, …►Transactions, failure transparency, discountchecking, system-level undo, linear typesystems, regions, guide, purely staticmethods, more general exceptions,workflow, flowmark, Barbara Liskov, vino, …

All are imperfect fits for this area.All are imperfect fits for this area.

ConclusionConclusion

►Many sources of run-time errors in code►Many sources of run-time errors in code

And we’re adding new ones with CCured, etc.And we’re adding new ones with CCured, etc.

►Run-time is only “too late” if unhandled►Run-time is only “too late” if unhandled

►What to do when a run-time error occurs?►What to do when a run-time error occurs?

►Difficult to specify!►Difficult to specify!

►Let’s make it easier to code up.►Let’s make it easier to code up.

►Future: automatic inference►Future: automatic inference

For standard libraries and interfacesFor standard libraries and interfaces