Exceptions & Exception Handling Mechanisms

1. Exceptions&Exception Handling Mechanisms

2. Exceptions • Exceptions • Definition • Declaration • Nature of exceptions

3. Exceptions • Definition • Exceptions are unusual events or error conditions that occur during run time • Such an event will result in a change of normal control flow. • E.g. Failing to dial a prefix 9 in IIT telephone network while calling a number outside the IIT network.

4. Exceptions • What events are unusual depends on the application and the situation that leads to those events • An exception in one case may not be so in another • E.g. Dialing prefix 9 in a telephone that is outside the IIT network.

5. Exceptions • The severity of an exception also depends mostly on the application under consideration and the situation in which the exception has occurred. • E.g. • A wrong number in a telephone application will result only in a wrong call being placed. • But a wrong number in a life support system controller may end up fatal.

6. Exceptions • So, • exact list of exceptions for an application is defined by the developer • that decision will be based on the application under consideration.

7. Exception Declaration • As any other object in the software paradigm there should be a way to represent exceptions • This has some important objectives, • Exceptions should be made explicit to the programmers so that they can consciously and cleverly utilize them in building robust applications. • The compiler will be able to aid the developers in various ways once they understand the exception objects, their type, binding, scope etc.

8. Exception declaration • To help programmers as we have mentioned above we need the following, at least. • Give each instance of each exception type a unique identification. • Once the exception has been identified, we need additional information about the cause of that exception • The requirements are not limited to just the list here.

9. Exception declaration • Exceptions are being represented in different ways. A few popular examples are, • Return value and flags • UNIX signals • Objects in OOP languages • We will examine each one of these mechanisms later in this presentation.

10. Nature of exceptions • Exception can be classified as • synchronous • asynchronous • user unaware • The above classification is from the aspect of the developer so that we can estimate how well one can be prepared to handle exceptions of the above categories.

11. Nature of exceptions • The synchronous ones are those that occur because of the actions of the execution in which they occur. • The executions are responsible for the exceptions that they have to face. • E.g. try-catch mechanism, return value indication.

12. Nature of exceptions • Asynchronous ones are those that occur in an execution different from the one where the exception is present. This occurs because of something not done by the execution that gets the exception. The exception is then propagated to the destination exception where it will be handled. • E.g. One thread stopping another thread using the signal mechanism

13. Nature of exceptions • User unaware exceptions: • A method calling another will not be aware of all the exceptions that could be thrown by the called method. • This problem plagued C++. • E.g. • If a developer has to use a class developed by someone else, he may not always have access to the source code. • All the developer can have for sure is the interface of that class. So there is no practical way he or the compiler can check and handle the exceptions thrown by that class or by another class used in that class.

14. Exception Handling Mechanisms • Exception Handling Mechanism • Purpose • Definition (What is EHM?) • Declaration • Nature of exception handling

15. Exception Handling Mechanism • Why do we need exceptions and exception handling mechanism • Unusual events or errors are not uncommon in software products. • We have exceptions to address such events. • Having identified exceptions we need a way to process them. • The mechanism to process such exception events is called as Exception Handling Mechanism

16. Exception Handling Mechanisms • Exception handling is a programming language facility for the programmer to specify how an exception should be handled. • E.g. • try-catch mechanism in Java • Signal mechanism in Unix

17. Exception Handling Mechanisms • They (Exception Handlers) process the exceptions trying to recover from the error condition or to terminate in the best possible way. • Best possible way implies “minimal damage” to the state of the system under consideration. • Preserving the state variables

18. Exception Handling Mechanisms • The importance of EHM will be best understood by looking at the impact of a EHM on the resulting software products, • A poor exception handling mechanism might result in many or all of the following situations. • Reliability? • Stability? • Defining new exceptions?

19. Code Tangling (Actual code and exception code) • Indecipherable code • Finding and fixing bugs will be difficult • Reverse engineering - a Herculean task. • Adding new software modules • Modifying existing software modules • Might result in code redundancy/duplication, • if the same exception needs to be handled in the same way in different parts of the program.

20. Nature of exception handling • Having discussed about the purpose and importance of exception handling, let us look at the choices we have in exception handling. • 1) Termination • 2) Retry • 3) Resume

21. Termination. • First popular mechanism • The code after that point, at which an exception occurs, will not be executed. • i.e. the execution is terminated at the point at which an exception occurs • Once everything is done, in ideal case it will look as if the execution terminated normally just before the exception point as if the exception never occurred

22. Termination.

23. Termination example try { buf = new char[512]; if( buf == 0 ) throw "Memory allocation failure!"; strycpy (buf, “This is a Test String”); } catch( char * str ) { cout << "Exception raised: " << str << '\n'; }

24. Retry Model • In this model, the handler will try to clean up the environment resulted from the exception and will try to restart the execution. • The original environment at that point of execution should be restored. • This includes all the status flags, program counter etc.

25. Retry Model • So the environment should be stored each time the execution crosses a restart point, irrespective of whether there will be an exception or not. • This is obviously an additional overhead (this was not there in termination model)

26. Restart point This part of the code will be executed again Retry Model

27. Retry model – restart point • Care should be taken while deciding the restart points. • If chosen too closely the overhead of saving the environment will be high. • If chosen too sparsely, when restarted from an exception too much of code will be repeated possibly resulting in more damage (like many files could have been changed etc) and poor performance.

28. Retry model – restart point • In general the starting point of a guarded block will serve as the restart point • It could be logical too, depending on the application under consideration. • E.g. A bank may want to restart from a point where processing a record starts. This makes sense because starting somewhere else will result in partial processing of a record (if a new record is fetched to restart) or doing some part of the processing for a particular record twice (if the same record is used to restart).

29. Retry model – E.g. using return value mechanism main(int argc, char **argv) { … int retry_count = MAX_RETRY; while ( retry_count- -) { if ((hp = gethostbyname(hostname)) == 0) { perror("gethostbyname"); continue; } /* fill in the socket structure with host information */ … if ((sd = socket(AF_INET, SOCK_STREAM, 0)) == -1) { perror("socket"); continue; } /* connect to PORT on HOST */ if (connect(sd,(struct sockaddr *) &pin, sizeof(pin)) == -1) { perror("connect"); close(sd); continue; } } //while if (! retry_count) exit(1); }//main

30. Resumption Model • The handler does the work of cleaning up the damage resulted because of the exception • Then control is transferred to the point next to the one where the execution flow was interrupted because of the exception and the execution continues from there on.

31. Resumption Model • the environment should be saved so that when the handler is done with its job, the control can be returned back to the point where the exception occurred. • When the control is returned a clean environment will be provided using the saved copy.

32. Resumption Model Exception point and restart point

33. Resumption Model • One can say that the resume model is nothing but the retry model • the retry point is each line of code in the execution • i.e. after executing each line the environment should be saved

34. Resumption model – E.g. using return value mechanism main(int argc, char **argv) { … int retry_count = MAX_RETRY; while ( retry_count- -) { if ((hp = gethostbyname(hostname)) == 0) { perror("gethostbyname"); continue; } /* fill in the socket structure with host information */ } //while … while ( retry_count- -) { if ((sd = socket(AF_INET, SOCK_STREAM, 0)) == -1) { perror("socket"); continue; } /* connect to PORT on HOST */ } //while while ( retry_count- -) { if (connect(sd,(struct sockaddr *) &pin, sizeof(pin)) == -1) { perror("connect"); sleep(17); continue; } } //while if (! retry_count) {close(sd); exit(1);} }//main`

35. Resumption Model • Though resume seems to be the best solution at hand, there are limitations. It does not resume exactly restoring everything. • E.g. if the source execution had incremented a counter in a file and while closing the file encountered an exception. The handler will not have enough knowledge to restore the counter in the file

36. Resumption Model • Things like this cannot be fixed and might result in fatal damages depending on the situation. • Thus we can say that the EHM does not guarantee a complete recovery from an exception. It merely attempts to minimize the damage

37. Propagation mechanism • Responsible for delivering the exception to the correct handler • The propagation execution can be different from the source execution and the faulting execution • OR one of those two (source / faulting) can have the propagation functionality in itself.

38. Propagation mechanism • In order to deliver the exceptions at the correct destination, the propagation mechanism sometimes has additional work • E.g. Unwinding the stack while navigating up in the function call tree in try-catch mechanism

39. Propagation mechanism • Propagation mechanism can be one of the following, • Static • Dynamic • This classification is based on the way the destination is chosen by the propagation mechanism.

40. Static propagation • In Static propagation the handler that will be used in a particular case will be known during compile time • A sequel has routines associated with it. • Exceptions are defined as sequels. When an exception is raised the sequel used to indicate that exception is called.

41. Static propagation • This sequel is hard coded and the exception handler is available during compile time. • The sequel proposed by Tennent is an example of static propagation.

42. Static propagation - example class stack { stack( sequel overflow(...) ) { ... } void push( int i ) { ... raise overflow(...); } }; { sequel StackOverflow(...) { ... } stack s( StackOverflow ); ... s.push( 3 ); // causes overflow } The handler routine is passed as a parameter to the constructor Exception Handler routine in this case

43. Dynamic propagation • The propagation model decides the handler to which the exception should be delivered. • The decision is made at run-time. • The decision usually depends on the type of exception thrown. • Most widely used • E.g. Java try-catch mechanism

44. Dynamic propagation class stack { stack() { ... } void push( int i ) { ... throw overflowexception; ... throw generalStackException; } }; try{ stack s(); ... s.push( 3 ); // causes overflow } catch (OverflowException e ){ //handler1 } catch(OtherStackException e){ //handler2 } Handlers chosen depending on the exception

45. EXISTING EXCEPTION HANDLING MECHANISMS • Some of the today’s popular Exception Handling mechanisms, • Return value and flags • UNIX signal mechanism • Object oriented mechanism

46. Return value and flags • oldest exceptions handling mechanisms • still in use • exceptions are represented as numbers • value of the number decides the type of exception • numbers are usually return values of procedures.

47. Return value and flags • When procedures return control back to the caller they indicate any exception that may have occurred using the appropriate return values • The caller then checks the return value looking for any possible exceptions.

48. Return value and flags • In case of flags, • a flag is set to indicate error or exception. • The handler code is executed if a flag is set. • This is found by checking the flag bit whenever required.

49. Return value and flags • Problem with this mechanism • Multiple instances of an exception cannot be thrown • The second instance will overwrite the first by setting the respective flag • Numbers just convey the exception type • Does not carry any additional information

50. Return value and flags • Exception code and actual code are intermixed • One should check for all errors explicitly, a new error condition, requires changes in all calling programs. • All the developers will not have the same value for an exception i.e. no standard value for exception so not portable