Coursehero >> Alabama >> W. Alabama >> PLG 246

Course Hero has millions of student submitted documents similar to the one below including study guides, homework solutions, papers, exam answer keys and textbook solutions.

8, March 2002 March 8, 2002 Errors, Exception Handling, and Smart Pointers Overview Kinds of errors, fault vs. failure, common run-time errors Pre/post/invariants and robustness Exceptions and exception handling in C++ and Java Standard exception classes Hints on good exception handling Stack unwinding, "smart" pointers, ... and finally Kinds of errors or, When bad things happen to good (and bad) programs 1. lexical errors -- ill-formed tokens, 2. syntactic errors -- illegal combinations of legal tokens, e.g., for [ i=;"}[vec;; [ 3. (simple) semantic errors -- violations of the rules of the programming language. e.g., declaration before use const method changes object private data altered by child class All of the above are statically-determinable, and will be caught by the compiler. [See Horstmann, chapters 16 and 6] E RRORS A ND E XCEPTIONS 1 March 8, 2002 E RRORS A ND E XCEPTIONS 2 March 8, 2002 Fault vs. failure 4. Errors of intent -- Failure may or may not occur; the program may do something legal and "reasonable", just not what was expected. Usually, this related to the requirements. Either: (a) the requirements were wrong, incomplete, misunderstood, etc. or (b) you modelled the requirements correctly, but implemented them incorrectly. 5. Run time errors -- Failure does occur; usually, this involves a (semantic) violation of the (run-time) type system: e.g., division by zero, user-defined assertion failure, subscript out-of-bounds, RTTI failure, pointer corruption of data structure. (We will discuss this topic in some detail.) Often, we just use the term "bug" or "error", but it's more helpful to distinguish between fault and failure. Fault is the design flaw, the mistake someone made that (eventually) caused the system to fail (or not). It's a static phenomenon. Failure is the event that made you take notice that something is wrong; it's the crash, the bad output. May occur far from the fault. It's a dynamic phenomenon. These definitions come from engineering. Not every fault causes a failure! Code that's mostly correct but fails on some data. Code that does something "reasonable" that's not too far from correct behaviour. Use of "fault tolerant" engineering techniques (e.g., redundant backups). Faults in dead or infrequently-used code. Faults that require a particular set of circumstances to occur. E RRORS A ND E XCEPTIONS 3 E RRORS A ND E XCEPTIONS 4 March 8, 2002 March 8, 2002 Examples: Ariane5 code worked until rockets became faster. Most major disasters occur because of a perverse chain of events rather than due to single mistakes. What causes run-time errors? "The environment" Something external to the program goes bad and the system has to deal with it somehow. If you're very lucky, they occur at the same place and time. More commonly, the failure occurs much later. e.g., pointer corruption of memory goes undetected until seg fault. Weakly-typed languages like C that do little run-time checking. Systems with long-lived complicated state. "Ambitious design/flexible logic" In the interest of generality, you permit a great deal of flexibility (and therefore risk) by permitting actions that could go wrong. Eventually, some (illegal) scenario arises that you didn't foresee (or successfully guard against). e.g., just about any division might be division by zero! Building tight, fierce, enforced abstractions cuts down on but does not eliminate these kinds of failures. This is why it's especially important to program defensively when using languages that do little checking. Good interface design, state-reporting functions, use of assertions, etc. E RRORS A ND E XCEPTIONS 5 March 8, 2002 E RRORS A ND E XCEPTIONS 6 March 8, 2002 What do you do when something goes wrong? Common kinds of environmental errors [Horstmann] 1. Report problem to stderr, but carry on bravely. OK if fault not fatal, e.g., missing </ul> tag, 2. Recover if you can make other arrangements e.g., couldn't find desired font so use a similar one e.g., try another network route 3. Rebuild missing information e.g., unfold answer from redundant backup or cache or transaction list 4. Backup from pending operation and refuse to process it, but carry on with other operations. 5. Die with dignity: clean up, save any data, and exit gracefully. 6. Sudden death -- e.g., an assertion failure and/or an error message. (Usually) better than just ignoring the error, but often it's not a realistic option. This approach is OK for undergrad assgts, but not for production-quality software systems. Bad user input -- e.g., file doesn't exist, "age" not an integer, corrupted/missing/inappropriate/bad version of data file. Device error/hardware failure -- can't find network, device is unplugged/fails, device (e.g., sensor in nuclear reactor) returns impossible/garbage data. Resource exhaustion -- e.g., run out of memory and can't new an object, disk fills up, denial of service (attack or accident). (Software) component failure -- a piece of code your systems uses (but is not part of your system) fails for some reason. e.g., library, (purchased) COTS components, EJB, database E RRORS A ND E XCEPTIONS 7 E RRORS A ND E XCEPTIONS 8 March 8, 2002 What is m().pre is not satisfied, but you call m() anyway? March 8, 2002 Pre-conditions, invariants, and post-conditions For any class C, the invariant must be true immediately following the call to any constructor of C. Furthermore, all methods m() (defined within C or inherited) must satisfy the following: If cobj is an object of class C and if C's invariant holds for cobj then if m()'s pre-condition is met then: 1. a call to m() will terminate, 2. m()'s post-condition will hold after, and 3. the class invariant will hold for cobj after. Note that you're allowed to temporarily break the invariant while performing m(); you just have to ensure that you re-establish it it just as you finish m(). The logical answer is that anything could happen -- nothing is guaranteed, not the post-condition, nor the invariant, nor even termination of m(). e.g., int binSearch (vector<Empl*> v, int eNum); has pre-condition that v is sorted (or may go into infinite loop). This is just a concocted example; some implementations of binary search may indeed halt even on unsorted data. However, there are many functions that use loops where the exit condition cannot be guaranteed to be achievable unless the precondition holds; imagine we chose one of those. This is also a good reason to hide variables as private! Clients can't make mistakes and violate invariants (accidentally or otherwise). The more control you maintain over the variables, the easier it is to control data (and therefore semantic) integrity. [See also Horstmann chapter 6, but this should be review from CS134.] However, usually it's not acceptable practice to return garbage or trash the system -- we require our systems to be more robust than that. E RRORS A ND E XCEPTIONS 9 March 8, 2002 E RRORS A ND E XCEPTIONS 10 March 8, 2002 An example What is the appropriate pre/post for binSearch? int binSearch (vector<string> v, string val); if you check before each use. If you were not intending to change the list often, you could call it once at the beginning and the again only after changes were made. Probably you would make changes in batches, which would require using a cache of "uncommitted" additions and checking the cache when doing a lookup. In this way you would amortize the cost of the checking. This is precisely the sort of issue that software engineers need to address: ensuring mathematical correctness as well as practicality. Pre: v is sorted Post: Let N v size N and let r be the return value N vi val r " i N i N vi val vr val ! (v is unchanged) (val is unchanged) Get input from students; provide trivial implementations. Note that in case of multiple hits, post doesn't say which index is returned. How do we make it robust? Count number of loop iterations, exit at mucks with the core algorithm. logN (or N). However, this # # Other ideas? Check that it's sorted before calling. This is O(N) which is unacceptable E RRORS A ND E XCEPTIONS 11 E RRORS A ND E XCEPTIONS 12 March 8, 2002 Robustness Robustness is about recovering from errors in a reasonable way. e.g., If I type in "fifteen" when the program asks for my age ... Production-quality software systems have to be robust, particularly if they are part of engineering systems. This is detailed, involved work; it often requires going over combinatorially many input scenarios. Often, a large percentage of the code in industrial software is devoted to input validation, error checking, and exception handling. However, embedding lots of error-checking code within the "normal" program application logic distracts from the coherence of the overall functional design. The preferred solution is to allow for the control flow of error checking to be done in a way that is both hierarchical and orthogonal to the design of the "main functionality". This is called exception handling. March 8, 2002 Note that this kind of error handling is not (usually) part of the core semantics of the basic system you've built: It's the exceptions to the rules. Unless you are dealing with raw user input, it doesn't make sense to check that all data is valid at every single moment. Moral: Pick your fights, probably at subsystem boundaries. In summary, we typically specify error handling separately from the main functionality of the system because: It's an orthogonal issue to the basic functionality, so it makes sense to make the error handling orthogonal too. We may change our minds about error-handling strategies w/o changing the semantics of normal correct behaviour. E RRORS A ND E XCEPTIONS 13 March 8, 2002 E RRORS A ND E XCEPTIONS 14 March 8, 2002 Exception handling in C++ and Java Same basic idea, tho the implementations and assumptions vary somewhat. Basic idea: When you notice something bad has occurred that you're unable or unwilling to deal with yourself, you throw an exception that is (eventually) caught by someone who "called" you (perhaps a few levels down the call stack). Exceptions don't do very much by themselves. Their state usually consists of a string error message (that is set by the exception thrower). The string should be used only for printing. If you want to check what kind of error was thrown, ask about the dynamic type of the exception! What's interesting about them is their underlying class. Exceptions are typed -- they are (usually) instances of a class. Both C++ and Java have predefined exception class hierarchies; you are encouraged to subclass them in your application program. Don't worry about overhead of dynamic querying for the type of an exception; you have more important things to worry about now. If an exception has been thrown, something truly "exceptional" has occurred and you need to fix it. E RRORS A ND E XCEPTIONS 15 E RRORS A ND E XCEPTIONS 16 March 8, 2002 March 8, 2002 Don't use exceptions as part of the normal control flow of your program! It's unwise. In C++, the "flexibility" of the throw/catch mechanism may cause your program to abort if you accidentally miss a case. Conceptually, it's the wrong thing to do. Normal control flow logic should be implemented using normal control flow mechanisms. It's usually grossly inefficient. Most current compilers implement exception handling much less efficiently than normal control flow. Typically, an exception is caught by a method that (transitively) called the thrower. The exception is then "handled" by this method, or rethrown to be caught by someone else lower in the call stack. An exception is not handled by the exception itself! Usual OO design philosophy says that objects should know what's best for themselves. However, exceptions are really just fancy error messages; they don't know enough about the problem and its context to do anything useful. E RRORS A ND E XCEPTIONS 17 March 8, 2002 E RRORS A ND E XCEPTIONS 18 March 8, 2002 An example calls SystemMgr A stack or other ADT might normally throw two kinds of exceptions: 1. Incorrect use (e.g., popping an empty stack), 2. Resource exhaustion (e.g., can't create another node). It would be exceedingly awkward to have to check for and handle these exceptions in every place where the ADT is used. Instead, it's common to let the exception be handled at a (single) higher level in the system. instantiates S1 calls S2 instantiates S3 MyVector MyQueue E RRORS A ND E XCEPTIONS 19 E RRORS A ND E XCEPTIONS 20 March 8, 2002 March 8, 2002 // An overview of the general case; coarse structure is shown, but details are left out. void SystemMgr::processReq () throw (IllegalAccess, ResourceExhaustion) { try { // // // // // // A simple example in full detail. // File: "MyADTUnderflow.h" #ifndef _MYADTUNDERFLOW_H_ #define _MYADTUNDERFLOW_H_ #include<string> #include<stdexcept> using namespace std; class MyADTUnderflow : public runtime_error { public: MyADTUnderflow(const string s) throw(); virtual ~MyADTUnderflow() throw(); }; // These definitions could be in "MyADTUnderflow.cc" MyADTUnderflow::MyADTUnderflow(const string s) throw() : runtime_error(s) {} MyADTUnderflow::~MyADTUnderflow() throw () {} #endif /* _MYADTUNDERFLOW_H_ */ <Code that calls S1, S2, S3 directly or indirectly> (see diagram for details of what might be raised) If S1 or S2 raise an exception, it will come to me immediately. If S3 raises an exception, it will pass through S2 to me. ... } catch (MyADTOverflow& e) { // eg pushing onto a full stack if (canGrabMoreSpace) { // Grab a bigger hunk of space by deleting some of my // personal cache and ask my ADT class to try again. // ... } else { throw ResourceExhaustion ("Out of memory"); } } catch (MyADTUnderflow& e) { // eg popping an empty stack // Throw an exception of the class expected by the caller; // copy over the error message to the new exception. throw IllegalAccess(e.what()); } } E RRORS A ND E XCEPTIONS 21 March 8, 2002 E RRORS A ND E XCEPTIONS 22 March 8, 2002 // File: "MyStack.h" #ifndef _MYSTACK_H_ #define _MYSTACK_H_ #include <vector> #include "MyADTUnderflow.h" template <typename T> class MyStack { public: MyStack(); virtual void push (T val); virtual T pop () throw (MyADTUnderflow); virtual int size (); virtual ~MyStack(); private: vector<T> v; }; // ... cont'd // File: "MyStack.h" (cont'd) // "Ignore the man behind the curtain." // Templated class definitions pretty much have to be in the .h file. template <typename T> MyStack<T>::MyStack<T>() : v() { } template <typename T> MyStack<T>::~MyStack<T>(){} template <typename T> void MyStack<T>::push (T val) { v.push_back(val); } template <typename T> T MyStack<T>::pop () throw (MyADTUnderflow) { if (v.empty()) { throw MyADTUnderflow("Popped empty stack"); } else { T returnVal = v.back(); v.pop_back(); return returnVal; } } template <typename T> int MyStack<T>::size() { return v.size(); } #endif /* _MYSTACK_H_ */ E RRORS A ND E XCEPTIONS 23 E RRORS A ND E XCEPTIONS 24 March 8, 2002 Retry // File: main.cc #include <iostream> #include <string> #include "MyADTUnderflow.h" #include "MyStack.h" using namespace std; int main (int argc, char* argv[]) { try { MyStack<string> s; s.push("hello"); s.push("there"); s.push("world"); // Should throw exception last time through const int numElts=s.size(); for (int i=0; i <numElts+1 ; i++) { string val = s.pop(); cout << "i = " << i << " Popped: " << val << endl; } } catch (MyADTUnderflow &e) { cout << "Caught MyADTUnderflow: " << e.what() << endl; } } March 8, 2002 Sometimes exceptions can be handled just by trying again e.g., network congestion, resource allocation bool success=false; int numTries=0; // keep retrying; exit on success or eventually throw runtime_error while (!success) { try { // code that may throw exception success=true; } catch (exception &e) { // may need to do a little handling } if (!success) { // must have thrown exception numTries++; if (numTries>MaxTries) { throw runtime_error ("Retried and failed"); } } } E RRORS A ND E XCEPTIONS 25 March 8, 2002 E RRORS A ND E XCEPTIONS 26 March 8, 2002 Another example An http "manager" takes http transaction requests from the rest of web-based e-commerce system, which it implements as several classes. However, two kinds of exceptions might be raised: 1. Can't connect (network request times out) 2. Illegal access (error 404, no such server, etc.) The http manager might choose to rethrow the illegal access requests to the caller while buffering the failed network requests until the network is available again (or until a timeout), then retry. In this case, there might be two user-defined exception classes: NetworkInaccessible and IllegalRequest. Note that we just pass on IllegalRequest to the caller, since we don't handle it explicitly. // HttpProcessor is the public interface to this subsystem/namespace; see also p436 Horstmann. void HttpProcessor::ProcessRequest(HttpRequest &req) throw (NetworkInaccessible, IllegalRequest) { const int MaxTries=5; int numTries = 0; bool success=false; while (!success) { try { // Make appropriate calls to other subsystem collaborators; these // classes/methods might throw NetworkInaccessible or IllegalRequest // ... <code block 1> // If we got to here, then no exceptions were raised // and we'll exit the loop at the next test. success=true; } catch (NetworkInaccessible& e) { numTries++; if (numTries<=MaxTries) { // Do some handling if needed and then try code block 1 again. } else { // Give up; rethrow to caller. Clean up any mess first tho. throw e; } } // implicitly pass on IllegalRequest to caller } // Assume no exceptions will be raised from now on. // ... <code block 2> } E RRORS A ND E XCEPTIONS 27 E RRORS A ND E XCEPTIONS 28 March 8, 2002 A look at the details Catching an exception [We assume C++ unless otherwise stated.] March 8, 2002 You throw an exception by creating and throw-ing an instance of an exception class, usually instantiated with a diagnostic string message: if (noSuchPage) { throw IllegalRequest ("Error 404 -- Page not found"); } If you call a method that might throw an exception, then basically you have two choices:a 1. Declare yourself as also throwing this exception and do nothing special. 2. Catch and handle the exception yourself. In this case, you put the calls to the potential thrower inside a try block, and catch the various exceptions right afterward. If you try to catch more than one kind of exception, the logic is the same as a cascaded if statement. (You could declare an object e first and then throw e, but typically we combine the two steps.) Note that the execution of the method stops dead when an exception is thrown -- you don't have to worry about what kind of dummy value to return when popping an empty stack. Once an exception is thrown, you look to the calling method to see if it handles the exception. If not, go to its caller, etc. There should be some calling ancestor that catches and handles any exception that might be thrown. is the recommended approach for most cases; C++ and Java permit some flexibility on this, as we'll see. a This RRORS E A ND E XCEPTIONS 29 March 8, 2002 E RRORS A ND E XCEPTIONS 30 March 8, 2002 void aClass::aMethod () { // This is C++ try { // some code that might raise an exception } catch (EKind1& e) { // do something appropriate } catch (EKind2& e) { // do something appropriate } catch (...) { // The "catch-all" clause; this will catch any // exception not previously caught. // Yes, you really do use three dots. } } Exceptions are (usually) instances of (normal) classes, descended from std::exception (C++) or Throwable (Java). Can use normal polymorphism to catch a range of related exceptions. e.g., NetworkError has subclasses NetworkUnreachable, ... Can catch all Network errors by catch (NetworkError& e); In C++, you should catch a reference to an exception class. If you don't then you risk ending up using the parent's copy constructor to create a brand new object; in this case you would lose all information specific to the child exception that was originally thrown because of this object slicing! E RRORS A ND E XCEPTIONS 31 E RRORS A ND E XCEPTIONS 32 March 8, 2002 March 8, 2002 In Java, you are required to be explicit about all checkeda exceptions that you might encounter; this is enforced by the language/compiler at compile-time. If you call a method that is declared as throwing a checked exception, then either: 1. you must catch and handle the exception yourself completely, or 2. you must declare yourself as (possibly) throwing that exception. Since main (usually) throws no exceptions and since it's at the bottom of the call stack, this guarantees that all checked exceptions will be caught and handled. In C++, you don't have to declare which exceptions you handle. That is, by default any function is assumed to be able to throw any kind of exception! If you do give a throw list of exceptions, you may throw only those. If you somehow throw another kind, the program will abort, even if you were intending to handle it elsewhere. In C++, if an exception makes it all the way to the bottom of the call stack without being handled, the program aborts! Usually this means without exiting gracefully or saving user data. a More on checked vs. unchecked Java exceptions later. E RRORS A ND E XCEPTIONS 33 March 8, 2002 E RRORS A ND E XCEPTIONS 34 March 8, 2002 "Careful with those hacks", Eugene In Java, the approach is safer and cleaner! You can statically guarantee that all exceptions will be caught and you, as the system maintainer, can easily trace the logic of the handling path. Some might call this a B&D or language fascist approach. It requires stating everything up front, more typing, less flexibility, ... [FYI "Careful with that axe, Eugene", is an old Pink Floyd song.] According to Horstmann, some C++ programmers use throw only as a kind of documentation. The problem with this is that is you list the exceptions you claim to throw but somehow you throw one that's not in your list (typically because you rethrew one you caught), then the system will abort. The C++ approach is more "flexible". You can do what you think is appropriate and later change your mind easily. More importantly, it's also backwardly compatible with C and older C++ systems (exception handling is pretty new to C++). You don't have to touch (and risk breaking) that legacy code; however, it makes the design (esp. the logic of exception handling) much harder to follow. Morals: In C++, use throw religiously or not at all, even if you do catch and throw exceptions. If you don't have to deal with legacy code issues, then use throw religiously, as Java insists you do. "Comments" should be embedded as comments, not code! E RRORS A ND E XCEPTIONS 35 E RRORS A ND E XCEPTIONS 36 March 8, 2002 Exception hierarchies C++ exception taxonomy It's common to define your own exception classes, but usually they should inherit from a "standard" exception class. Here's the C++ model: #include<exception> exception March 8, 2002 Errors that are the programmer's fault should derive from logic error. Something bad happened due to a design flaw e.g., bad pointer, forgot to sort vector, v.at(-2) throws out of range Retrying later probably won't help since the program design is wrong. Usual approach: Note the symptoms, report as a defect and have a programmer debug and fix the offending code. logic_error runtime_error bad_alloc #include<new> bad_exception #include<exception> domain_error invalid_argument underflow_error overflow_error bad_typeid #include<typeinfo> bad_cast #include<typeinfo> length_error out_of_range #include<stdexcept> range_error Errors that are caused by external conditions should derive from runtime error. Usual approach: Might want to wait and retry in case network comes back up or more memory becomes available. You must #include the appropriate file; these exceptions are in the std namespace. E RRORS A ND E XCEPTIONS 37 March 8, 2002 E RRORS A ND E XCEPTIONS 38 March 8, 2002 What you can throw in C++ The use of std::exception as the "mother of all exception classes" is convention only. You are strongly advised to follow this convention! Errors thrown by the run-time system: Failed instantiation throws bad alloc. Illegal dynamic cast throws bad cast (if used with reference types) Illegal typeid passed to RTTI throws bad typeid. In C++, you can throw any kind of entity! e.g., an int, a GraphicalCowboy, a "fat" exception object with lots of embedded context information, ... This is most common in older code (i.e., pre ASNI exception specification) that contains exception handling. For example, ints that represent globally-known error conditions, homebrew exception objects, ... This is why it's not enough to say catch (std::exception &e) if you want to catch all possible exceptions. Use catch(...) instead. Finally, bad exception is thrown by programmers if they catch an exception they aren't expecting (usually via catch(...)) and don't quite know what to do with it. E RRORS A ND E XCEPTIONS 39 E RRORS A ND E XCEPTIONS 40 March 8, 2002 Nitty gritty details (g++ v3.0.2)a exception and its descendants support a public what() method to return an error message (usually the one the caller gave at throwing time): virtual const char* what () const; exception, bad exception, bad cast, bad alloc, bad typeid define only a trivial constructor and destructor; you can't instantiate them with a string message. The C-string value returned by what() for these classes is not specified by the ANSI standard. g++ v3.0.2 returns the results of a call to typeid().name(); you may provide your own definitions if you prefer. These exceptions are typically thrown by the runtime system; they are caught in (but rarely thrown by) generic application code, and they are not commonly subclassed. I really did read the source code. March 8, 2002 logic error and runtime error define a constructor that takes a string message. what() is redefined to print this message. Subclasses just provide trivial constructor/destructor. Most user-defined exception classes inherit from one of these two classes (or their children). a Yes, E RRORS A ND E XCEPTIONS 41 March 8, 2002 E RRORS A ND E XCEPTIONS 42 March 8, 2002 Java exception hierarchy Here's an example exception class definition: Throwable class IllegalRequest : public logic_error { public : // Promise to "throw" nothing, just like your parent. IllegalRequest (const string& s) throw() ; virtual ~IllegalRequest () throw() ; }; IllegalRequest::IllegalRequest (const string& s) throw() : logic_error(s) {} IllegalRequest::~IllegalRequest () throw() {} Error Exception has 55 direct children in JDK 1.4! IOException RuntimeException [It really is this simple.] E RRORS A ND E XCEPTIONS 43 E RRORS A ND E XCEPTIONS 44 March 8, 2002 Java exception hierarchy Unlike C++, only instances of classes that descend from Throwable can be thrown and caught. For convenience, we'll use the term Java exception to mean an object that is Throwable. IOException is a common basetype for IO exceptions. March 8, 2002 Error models internal system errors and resource exhaustion. You can catch them, but only the runtime system should throw them. Usually it's OK not to worry about them as there's nothing you can do. You shouldn't create your own descendants from Error. User-defined exceptions typically inherit from Exception or one of its many, many predefined descendants. In particular, there's no direct analogue of C++'s runtime error. RuntimeException models what in C++ is called a logic error (!!!) i.e., the programmer made a mistake. e.g., NullPointerException, ArithmeticException, ArrayIndexOutofBoundsException You can catch but shouldn't throw RuntimeExceptions; it's also common just to let the runtime system deal with them. E RRORS A ND E XCEPTIONS 45 March 8, 2002 E RRORS A ND E XCEPTIONS 46 March 8, 2002 Checked and unchecked exceptions Descendants of Throwable may be checked or unchecked. Unchecked exceptions: ... by definition, is any descendant of Error or RuntimeException. Usually, something has gone very wrong, and there's not much the programmer can do about it. Often, these come about by actions that usually do not cause a problem. e.g., Internal error in the running JVM, division by zero. You may, but are not required to, catch unchecked exceptions. You may, but are encouraged not to, create your own unchecked exception classes. Sometimes, Java programmers create their custom exception classes as subclasses of RuntimeException out of laziness so they can selective decide if/when to bother declaring/catching exceptions. This is a Bad Thing. Checked exceptions: ... by definition, is any other descendant of Throwable/Exception. Usually, something unexpected happened in the outside world, but your program knows how to deal with it. If you call a method that throws a checked exception, then you must handle it or declare yourself as throwing it also. E RRORS A ND E XCEPTIONS 47 E RRORS A ND E XCEPTIONS 48 March 8, 2002 March 8, 2002 Hints on good exception handling Exceptions should be exceptional! [Horstmann] What to throw? Low-level routines should throw exceptions for any kind of errors they detect but cannot solve. Higher-level routines can the decide how to deal with these failures at a subsystem level. They should "fix" the problem and/or retry and/or just carry on, or they should report an error at the subsystem level to the caller (by throwing an exception). Note how this approach to error handling lends itself so nicely to hierarchical system design. Don't use it as a cheap GOTO or to return the value of a standard computation. Exceptions can cause your program to die! Try to do appropriate error checking, pre-condition validation etc. at the appropriate time and place. Reserve exception raising for "uh-oh, how did that happen?" i.e., you couldn't have easily fixed it or disallowed it yourself. E RRORS A ND E XCEPTIONS 49 March 8, 2002 E RRORS A ND E XCEPTIONS 50 March 8, 2002 What to catch? Exceptions that you can handle completely. Exceptions that require some handling by you (e.g., freeing a resource) before you rethrow for further handling by your caller. Let the others flow through you to your caller; don't feel the need to intercept every message/exception that passes through you. Sometimes you catch a whole family of exceptions (by specifying an exception base class), only to immediately rethrow the ones you don't handle yourself. Define your own exception classes, using the standard library hierarchy as the base classes. [C++ only] Watch out for heap-based objects becoming leaks. Watch out for unfulfilled protocol obligations. e.g., returning any acquired resources, opening a file requires closing it again, etc. Stack unwinding (and smart pointers) A big deal in C++ and a real chance for memory leaks if you're not careful; this is particularly important to do properly. Presumably if you've gone to the trouble of creating exception handlers, you have a large, robust program that runs for a long time. This means systematic memory leaks are a real concern for you! Suppose you throw an exception to be caught by a caller a few steps below you in the call stack. As you know, control passes to the handler nearest on the call stack. What about the pieces of storage you've created since then? E RRORS A ND E XCEPTIONS 51 E RRORS A ND E XCEPTIONS 52 March 8, 2002 March 8, 2002 Stack throw exception Heap Objects on the stack are deleted for you automatically (i.e., appropriate destructors are invoked). Partially constructed stack-based objects are deleted too! Note that if a destructor then throws an exception, the program aborts immediately. Moral: Don't throw exceptions in destructors. What about heap-based objects? They become a memory leak! ... unless you use a "smart pointer" that knows what to do in such a case, e.g., STL's auto ptr. catch exception main E RRORS A ND E XCEPTIONS 53 March 8, 2002 E RRORS A ND E XCEPTIONS 54 March 8, 2002 "Smart" vs. raw pointers Raw pointers in C++ are basically addresses of data with a bit more type safety than C pointers. However, it's legal and common to accidentally: access an object that's been deleted. delete an object that's already been deleted. An example 1. Using "normal" pointers: if (pigsCanFly) { Circle* rc = new Circle ("Red", 10, 10); rc->setSize(25); // do stuff delete rc; } Although the results of both actions are not defined. You would also like your pointers to be smart enough to "do the correct and obvious thing" wrt to object deletion. If a pointer is about to die and no one else is pointing to its object ... wouldn't it be nice if the pointer were somehow "smart" enough to delete the object too? The C++ Standard Library provides a smart pointer class called auto ptr, but it's not as smart as you might wish ... If rc->setSize(int) raises an exception, then delete rc is never executed, even if the system manages to recover from the exception. E RRORS A ND E XCEPTIONS 55 E RRORS A ND E XCEPTIONS 56 March 8, 2002 March 8, 2002 2. Using auto ptr: if (pigsCanFly) { auto_ptr<Circle> rc (new Circle ("Red", 10, 10)); rc->setSize(25); // do stuff } A smart pointer, such as auto ptr, is actually a templated object with an internal pointer variable that points to the heap object. A smart pointer class overloads the -> and * operators to make it feel like a real pointer. A smart pointer's destructor deletes the heap object it points to. Typically, smart pointer instances are created as stack-based objects. Thus, if an exception is raised, the smart pointer's destructor will be invoked, which in turn will delete the heap-based object it points to. If rc->setSize(int) raises an exception, then the object rc (as well as the heap-based Circle it points to) is deleted automatically during stack unwinding; otherwise, rc will be destroyed at the end of its enclosing block, just like any other stack-based object. E RRORS A ND E XCEPTIONS 57 March 8, 2002 E RRORS A ND E XCEPTIONS 58 March 8, 2002 auto ptr gotcha What about this: auto_ptr<Circle> rc (new Circle ("Red", 10, 10)); auto_ptr<Circle> rc2 = rc; auto ptr was designed to help avoid memory leaks in the presence of exception handling; it wasn't designed to be a general-purpose smart pointer. You cannot use auto ptr as the element type for STL containers. COAPs (containers of auto pointers) are explicitly illegal according the ANSI standard. It won't work the way you expect because of all of the copying that occurs; auto ptrs simply do not support value semantics. The problem is that auto ptr's implementation requires at most one owner for any object. But what you want if for the pointer to keep track of how many smart pointers are referring to the object, and call delete only when the count reaches zero This is called reference counting. There are (non-standard) smart pointer implementations that use this technique. Both rc and rc2 will be destroyed at the end of the current scope. Q: Does this mean the red Circle object will get deleted twice? A: No. To guard against this, auto ptr has unusual semantics for copying and assignment: Ownership of the object gets passed on to the target. The original owner (rc) no longer points to the object. rc sets an internal flag to indicate "I'm not valid". If rc tries to access the object, there will be a run-time error. E RRORS A ND E XCEPTIONS 59 E RRORS A ND E XCEPTIONS 60 March 8, 2002 March 8, 2002 Reference counting was also used for older languages (e.g., dialects of Lisp) that support GC. Reference counting is susceptible to the circular chains of garbage problem that we discussed earlier. i.e., There are no stack-based entity references the chain, but each element of the chain references another element of the chain, so the reference count of each element is at least one. Java uses a different algorithm ("mark-and-sweep") for GC. Summary on smart pointers If your system has exception handling and you create heap-based objects, then either: 1. you need to be really careful about memory leaks, or 2. you should use some kind of smart pointer for the heap-based objects. auto ptr is in the C++ Standard Library ... ... or you might consider using one of the non-standard but reliable smart pointers implementations, e.g., http://www.boost.org Nit: Horstmann's example usage style of auto ptr is (now) illegal: Balloon *cb = new Balloon("Cyan"); auto_ptr<Balloon> acb = cb; // Illegal auto_ptr<Balloon> acb2 (cb); // Correct Languages that uses GC (e.g., Java) don't have to worry about this. For CS246, you can ignore smart pointers for your assignments. E RRORS A ND E XCEPTIONS 61 March 8, 2002 E RRORS A ND E XCEPTIONS 62 March 8, 2002 ... and finally Java's use of GC means that you don't have to worry about stack unwinding and reclamation of heap-based objects. However, sometimes your program will have other "resources" that need to be managed by you. It is guaranteed that the finally clause will be executed, no matter what happens: If no exception is raised, the finally clause is executed just after the try block. If an exception is raised and caught locally, the finally clause us executed after the "local handling". If an exception is raised but not caught locally, the finally clause is executed just before the system starts to look up the call stack for a handler. e.g., a graphical entity that should be disposed of, an open file stream that should be closed, ... If you create a "mess" in the try block that needs to be cleaned up, you can put the cleanup code in a finally clause. C++ does not have a finally clause ... alas. E RRORS A ND E XCEPTIONS 63 E RRORS A ND E XCEPTIONS 64 March 8, 2002 // This is Java code adapted from an example in // "Core Java 2 vol. 1" by Horstmann and Cornell, p596 public class Mumble { // ... stuff public void blarg () { // ... other stuff Graphics g = image.getGraphics(); try { // Code that might raise an exception // ... } catch (SkyIsFallingException e) { // Do something appropriate // ... } finally { // Clean up the graphic g.dispose(); } } } E RRORS A ND E XCEPTIONS 65

Find millions of documents here - Study Guides, Homework Solutions, Papers, Exam Answer Keys and more. Course Hero has millions of course related materials that will enable you to learn better, faster and get an A in all your courses.
Below is a small sample set of documents: