CS 342 Lecture -*- Outline -*- * Exception Handling Problems with procedural abstractions May be partial maps e.g., cannot divide by zero read past end of file, or pop an empty stack May need to return "in different ways" e.g., instr$execute may halt or find a run-time error ** What is an exception? Exception: an unusual situation, that may require special processing. when it occurs the exception is said to be signalled (or raised) Exception handler: the special processing. e.g., return maximum integer, ask user for advice, exit a loop, ignore it, terminate program after closing files, etc. ** Is a language-defined exception handling mechanism necessary? Ways one might handle exceptions otherwise: *** require that caller insure that they don't happen pop = proc(s: stack) % REQUIRES: s is not empty % MODIFIES: s % EFFECT: remove the top element of s -problems: software less robust (insecure) makes debugging harder -however, sometimes this is useful for efficiency. But better way to ensure requirements is to use data abstractions *** status codes each procedure turns into a function that passes back a status code indicating success or error status := stream$getc(s,c) if status = EXCEPTION then % exceptional processing. end % normal processing -problems: inefficient in normal case no warning if users forget to check code (insecure) code for exceptional cases gets in the way (readability) hard to nest functional interfaces properly and check for exceptions at proper times. *** label parameters (gotos) subroutine jumps to exceptional label if needed possible in FORTRAN, Algol 60 -problems: slightly less efficient in normal case hard to communicate other information about exception (e.g., reason couldn't open file) *** pass procedure to be called in case of exception -problems: doesn't help unless that procedure can alter flow of control ** Trade-offs in langauge-defined exception mechanism *** benefits: more expressive, more secure more efficient (as we'll see) *** problems: more complex language ** Trade-offs in use of exceptions (exceptions vs. precondition) most of the time more secure to have an exception e.g. stack$pop sometimes too expensive to check ==> use precondition e.g., binary search of an array, checking that array is sorted takes O(n) time ** Exceptions in CLU (may omit) *** Where can exceptions be handled? in routine where exception detected? (not helpful) caller? (certainly) caller of caller? (makes it hard to read code, hard to have abstractions) **** single level model (CLU) only caller can handle exceptions in CLU **** multiple level model (Ada) Ada allows any routine on the dynamic chain to handle exception exceptions declared separately from procedures (names statically scoped) not part of procedural abstraction in Ada when exception is raised, search dynamic chain of blocks for handler (handlers dynamically scoped) exceptions continue to propogate, terminating activations until handled but not propogated outside program (or task). -advantage: no interactions with type system can handle exceptions that called subprogram does not know about (if has generic subprogram parameter) -disadvantage: less secure because caller does not know about the entire interface of callee *discuss this, consider: methodology (abstraction) ** Exceptions in Ada declared separately from procedures (names statically scoped) when exception is raised, search dynamic chain of blocks for handler (handlers dynamically scoped) -------- package INT_LIST is exception EMPTY_LIST; ... end INT_LIST; package body INT_LIST is ... raise EMPTY_LIST; ... end INT_LIST; declare use INT_LIST; begin ...CAR(NIL)... exception when EMPTY_LIST => put("took car of empty list"); when OVERFLOW => return 32; end ----------- exception handlers are only case in Ada where names are bound dynamically exceptions continue to propogate, terminating activations until handled but not propogated outside program (or task). -advantage: no interactions with type system can handle exceptions that called subprogram does not know about (if has generic subprogram parameter) -disadvantage: less secure because caller does not know about the entire interface of callee