Presentation is loading. Please wait.

Presentation is loading. Please wait.

Chair of Software Engineering Software Architecture Prof. Dr. Bertrand Meyer Lecture 6: Exception Handling.

Similar presentations


Presentation on theme: "Chair of Software Engineering Software Architecture Prof. Dr. Bertrand Meyer Lecture 6: Exception Handling."— Presentation transcript:

1

2 Chair of Software Engineering Software Architecture Prof. Dr. Bertrand Meyer Lecture 6: Exception Handling

3 2 What is an exception? “An abnormal event” Not a very precise definition Informally: something that you don’t want to happen…

4 3 Exception vocabulary  “Raise”, “trigger” or “throw” an exception  “Handle” or “catch” an exception

5 4 Java exceptions Exceptions are objects, descendants of Throwable:

6 5 Java: raising a programmer-defined exception Instruction: throw my_exception; The enclosing routine should be of the form my_routine (…) throws my_exception { … if abnormal_condition throw my_exception; } The calling routine must handle the exception (even if the handling code does nothing). To handle an exception: try … catch …

7 6 Checked vs unchecked exceptions Checked: raised by program, caller must handle Unchecked: usually raised by external sources, don’t have to be handled

8 7 How to use exceptions? Two opposite styles:  Exceptions as a control structure: Use an exception to handle all cases other than the most favorable ones (e.g. a key not found in a hash table triggers an exception)  Exceptions as a technique of last resort

9 8 Exception handling A more rigorous basis:  Introduce notion of contract  The need for exceptions arises when a contract is broken by either of its parties (client, supplier) Two concepts:  Failure: a routine, or other operation, is unable to fulfill its contract.  Exception: an undesirable event occurs during the execution of a routine — as a result of the failure of some operation called by the routine.

10 9 The original strategy r (...) is require... do op 1 op 2... op i... op n ensure... end

11 10 Not going according to plan r (...) is require... do op 1 op 2... op i... op n ensure... end Fails, triggering an exception in r (r is recipient of exception).

12 11 Causes of exceptions in O-O programming Four major kinds:  Operating system signal: arithmetic overflow, no more memory, interrupt...  Assertion violation (if contracts are being monitored)  Void call (x. f with no object attached to x) In Eiffel & Spec#, will go away

13 12 Total functions Let A and B be two sets  A total function from A to B is a mechanism associating a member of B with every member of A  If f is such a total function and a  A, then the associated member of B is written f (a)  The set of all such members of B is written range f The set of total functions from A to B is written A  B

14 13 Relations A relation r from A to B is a total function in P (A)  P (B) such that r (  ) =  and for any subsets X and Y of A, r (X  Y ) = r (X )  r (Y ) The set of relations from A to B is also written A B For r  A B X  A the set r (X ) is called the image of X by r Powerset

15 14 Functions (possibly partial) A function from A to B is a total function from X to B, for some X  A The set of functions from A to B is written A B  | The domain of a function f  A B, written domain f, is the largest subset X  A such that f  X  B  |

16 15 Total and partial functions Theorem 1: For any f : A B, there exists X  A such that f  X  B Theorem 2: For any f : A  B, for any X  A, f  X B  |  |

17 16 Using partial functions Convention: For f  A B and a  A, we may write f (a) (as for a total function) if we prove that a  domain f  |

18 17 Handling exceptions properly Safe exception handling principle:  There are only two acceptable ways to react for the recipient of an exception: Concede failure, and trigger an exception in the caller (Organized Panic). Try again, using a different strategy (or repeating the same strategy) (Retrying). (Rare third case: false alarm)

19 18 How not to do it (From an Ada textbook) sqrt (x: REAL) return REAL is begin if x < 0.0 then raise Negative; else normal_square_root_computation; end exception when Negative => put ("Negative argument"); return; when others =>  end; -- sqrt

20 19 The call chain r0r0 r1r1 r2r2 r3r3 r4r4 Routine call

21 20 Exception mechanism Two constructs:  A routine may contain a rescue clause.  A rescue clause may contain a retry instruction. A rescue clause that does not execute a retry leads to failure of the routine (this is the organized panic case).

22 21 Transmitting over an unreliable line (1) Max_attempts: INTEGER is 100 attempt_transmission (message: STRING ) is -- Transmit message in at most -- Max_attempts attempts. local failures : INTEGER do unsafe_transmit (message) rescue failures := failures + 1 if failures < Max_attempts then retryend

23 22 Transmitting over an unreliable line (2) Max_attempts: INTEGER is 100 failed: BOOLEAN attempt_transmission (message: STRING ) is -- Try to transmit message; -- if impossible in at most Max_attempts -- attempts, set failed to true. local failures: INTEGER do if failures < Max_attempts then unsafe_transmit (message ) else failed := True end rescue failures := failures + 1 retry end

24 23 Another Ada textbook example procedure attempt is begin > -- Start is a label loop begin algorithm_1; exit; -- Alg. 1 success exception when others => begin algorithm_2; exit; -- Alg. 2 success exception when others => goto Start; end end main; attempt local even: BOOLEAN do if even then algorithm_2 else algorithm_1 end rescue even := not even; retry end In Eiffel

25 24 Dealing with arithmetic overflow quasi_inverse (x: REAL ): REAL -- 1/x if possible, otherwise 0 local division_tried: BOOLEAN do if not division_tried then Result := 1/x end rescue division_tried := True retry end

26 25 If no exception clause (1) Absence of a rescue clause is equivalent, in first approximation, to an empty rescue clause: f (...) is do... end is an abbreviation for f (...) is do... rescue -- Nothing here end (This is a provisional rule; see next.)

27 26 The correctness of a class For every creation procedure cp : {Pre cp } do cp {INV and Post cp } For every exported routine r : {INV and Pre r } do r {INV and Post r } x. f (…) x. g (…) x. f (…) create x. make (…) S1 S2 S3 S4

28 27 Bank accounts balance := deposits. total – withdrawals. total deposits withdrawals balance (A2)

29 28 Exception correctness For the normal body: {INV and Pre r } do r {INV and Post r } For the exception clause: {???} rescue r {??? }

30 29 Exception correctness For the normal body: {INV and Pre r } do r {INV and Post r } For the exception clause: {True} rescue r {INV }

31 30 If no exception clause (2) Absence of a rescue clause is equivalent to a default rescue clause: f (...) is do... end is an abbreviation for f (...) is do... rescue default_rescue end The task of default_rescue is to restore the invariant.

32 31 For finer-grain exception handling Use class EXCEPTIONS from the Kernel Library. Some features:  exception (code of last exception that was triggered)  is_assertion_violation, etc.  raise (“exception_name”) Inheritance from class EXCEPTIONS is replaced in ISO/ECMA Eiffel by the use of exception objects (class EXCEPTION).

33 32 Dealing with erroneous cases Calling a. f (y) with f (x : T ) require x. property do … ensure Result. other_property end Normal way (a priori scheme) is either: 1. if y. property then a. f (y) else … end 2. ensure_property; a. f (y)

34 33 A posteriori scheme (from OOSC) a. invert (b ) if a. inverted then x := a. inverse else -- … Appropriate error action … end

35 34 Using agents (from Standard Eiffel) Scheme 1: action1 if ok1 then action2 if ok2 then action3 -- More processing, -- more nesting... end end Scheme 2: controlled_execute ([ agent action1, agent action2 (...), agent action3 (...) ]) if glitch then warning (glitch_message) end

36 35 Another challenge today Exceptions in a concurrent world Another talk…

37 36 Summary and conclusion Exceptions as a control structure (internally triggered): Benefits are dubious at best An exception mechanism is needed for unexpected external events Need precise methodology; must define what is “normal” and “abnormal”. Key notion is “contract”. Next challenge is concurrency & distribution

38 37 Complementary material OOSC2:  Chapter 11: Design by Contract


Download ppt "Chair of Software Engineering Software Architecture Prof. Dr. Bertrand Meyer Lecture 6: Exception Handling."

Similar presentations


Ads by Google