[17] Exceptions and error handling  Updated! 
(Part of C++ FAQ, Copyright © 1991-2011, Marshall Cline, cline@parashift.com)

FAQs in section [17]:

• [17.1] What are some ways try / catch / throw can improve software quality?
• [17.2] I'm still not convinced: a 4-line code snippet shows that return-codes aren't any worse than exceptions; why should I therefore use exceptions on an application that is orders of magnitude larger?
• [17.3] How do exceptions simplify my function return type and parameter types?
• [17.4] What does it mean that exceptions separate the "good path" (or "happy path") from the "bad path"?
• [17.5] Okay, so you're saying exception handling is easy and simple, right?  Updated! 
• [17.6] Exception handling seems to make my life more difficult; clearly I'm not the problem, am I??
• [17.7] I have too many try blocks; what can I do about it?
• [17.8] How can I handle a constructor that fails?
• [17.9] How can I handle a destructor that fails?
• [17.10] How should I handle resources if my constructors may throw exceptions?
• [17.11] How do I change the string-length of an array of char to prevent memory leaks even if/when someone throws an exception?
• [17.12] What should I throw?
• [17.13] What should I catch?
• [17.14] But MFC seems to encourage the use of catch-by-pointer; should I do the same?
• [17.15] What does throw; (without an exception object after the throw keyword) mean? Where would I use it?
• [17.16] How do I throw polymorphically?
• [17.17] When I throw this object, how many times will it be copied?

By eliminating one of the reasons for if statements.

The commonly used alternative to try / catch / throw is to return a return code (sometimes called an error code) that the caller explicitly tests via some conditional statement such as if. For example, printf(), scanf() and malloc() work this way: the caller is supposed to test the return value to see if the function succeeded.

Although the return code technique is sometimes the most appropriate error handling technique, there are some nasty side effects to adding unnecessary if statements:

• Degrade quality: It is well known that conditional statements are approximately ten times more likely to contain errors than any other kind of statement. So all other things being equal, if you can eliminate conditionals / conditional statements from your code, you will likely have more robust code.
• Slow down time-to-market: Since conditional statements are branch points which are related to the number of test cases that are needed for white-box testing, unnecessary conditional statements increase the amount of time that needs to be devoted to testing. Basically if you don't exercise every branch point, there will be instructions in your code that will never have been executed under test conditions until they are seen by your users/customers. That's bad.
• Increase development cost: Bug finding, bug fixing, and testing are all increased by unnecessary control flow complexity.

So compared to error reporting via return-codes and if, using try / catch / throw is likely to result in code that has fewer bugs, is less expensive to develop, and has faster time-to-market. Of course if your organization doesn't have any experiential knowledge of try / catch / throw, you might want to use it on a toy project first just to make sure you know what you're doing — you should always get used to a weapon on the firing range before you bring it to the front lines of a shooting war.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

Because exceptions scale better than return-codes.

The problem with a 4-line example is that it has only 4 lines. Give it 4,000 lines and you'll see the difference.

Here's a classic 4-line example, first with exceptions:

Here's the same example, this time using return-codes (rc stands for "return code"):

People point to those "toy" examples and say, "Exceptions don't improve coding or testing or maintenance cost in that; why should I therefore use them in a 'real' project?"

Reason: exceptions help you with real-world applications. You won't likely see much if any benefit on a toy example.

In the real world, the code that detects a problem must typically propagate error information back to a different function that will handle the problem. This "error propagation" often needs to go through dozens of functions — f1() calls f2() calls f3(), etc., and a problem is discovered way down in f10() (or f100()). The information about the problem needs to get propagated all the way back to f1(), because only f1() has enough context to actually know what should be done about the problem. In an interactive app, f1() is typically up near the main event loop, but no matter what, the code that detects the problem often isn't the same as the code that handles the problem, and the error information needs to get propagated through all the stack frames in between.

Exceptions make it easy to do this "error propagation":

Only the code that detects the error, f10(), and the code that handles the error, f1(), have any clutter.

However using return-codes forces "error propagation clutter" into all the functions in between those two. Here is the equivalent code that uses return codes:

The return-code solution "spreads out" the error logic. Functions f2() through f9() have explicit, hand-written code related to propagating the error condition back up to f1(). That is badness:

• It clutters functions f2() through f9() with extra decision logic — the most common cause of bugs.
• It increases the bulk of the code.
• It clouds the simplicity of the programming logic in functions f2() through f9().
• It requires the return value to perform two distinct duties — functions f2() through f10() will need to handle both "my function succeeded and the result is xxx" and "my function failed and the error information is yyy". When the types of xxx and yyy differ, you sometimes need extra by-reference parameters to propagate both the "successful" and "unsuccessful" cases to the caller.

If you look very narrowly at f1() and f10() in the above examples, exceptions won't give you much of an improvement. But if you instead open your eyes to the big picture, you will see a substantial difference in all the functions in between.

Conclusion: one of the benefits of exception handling is a cleaner, simpler way to propagate error information back to the caller that can handle the error. Another benefit is your function doesn't need extra machinery to propagate both the "successful" and "unsuccessful" cases back to the caller. Toy examples often don't emphasize either error propagation or handling of the two-return-types problem, therefore they don't represent Real World code.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

When you use return codes, you often need two or more distinct return values: one to indicate that the function succeeded and to give the computed result, and another to propagate the error information back to the caller. If there are, say, 5 ways the function could fail, you could need as many as 6 different return values: the "successful computation" return value, and a possibly different package of bits for each of the 5 error cases.

Let's simplify it down to two cases:

• "I succeeded and the result is xxx."
• "I failed and the error information is yyy."

Let's work a simple example: we would like to create a Number class that supports the four arithmetic operations: add, subtract, multiply and divide. This is an obvious place for overloaded operators, so let's define them:

It's very easy to use:

But then we have a problem: handling errors. Adding numbers could cause overflow, dividing could cause divide-by-zero or underflow, etc. Whoops. How can we report both the "I succeeded and the result is xxx" as well as "I failed and the error information is yyy"?

If we use exceptions, it's easy. Think of exceptions as a separate return type that gets used only when needed. So we just define all the exceptions and throw them when needed:

But if we use return codes instead of exceptions, life gets hard and messy. When you can't shove both the "good" number and the error information (including details about what went wrong) inside the Number object, you will probably end up using extra by-reference parameters to handle one of the two cases: either "I succeeded" or "I failed" or both. Without loss of generality, I will handle the computed result via a normal return value and the "I failed" case via a by-reference parameter, but you can just as easily do the opposite. Here's the result:

Now here's how to use it — this code is equivalent to the above:

The point of this is that you normally have to muck up the interface of functions that use return codes, particularly if there is more error information to propagate back to the caller. For example, if there are 5 error conditions and the "error information" requires different data structures, you might end up with a fairly messy function interface.

None of this clutter happens with exceptions. Exceptions can be thought of as a separate return value, as if the function automatically "grows" new return types and return values based on what the function can throw.

Note: Please don't write me saying that you propose using return codes and storing the error information in a global or static variable, such as Number::lastError(). That isn't thread-safe. Even if you don't have multiple threads today, you rarely want to permanently prevent anyone in the future from using your class with multiple threads. Certainly if you do, you should write lots and lots of BIG UGLY COMMENTS warning future programmers that your code is not thread-safe, and that it probably can't be made thread-safe without a substantial rewrite.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

It's another benefit of exceptions over return-codes.

The "good path" (sometimes called the "happy path") is the control-flow path that happens when everything goes well — when there are no problems.

The "bad path" (or "error path") is the path that control-flow takes when something goes wrong — when there is a problem.

Exceptions, when done right, separate the happy path from the error path.

Here is a simple example: function f() is suppoesd to call functions g(), h(), i() and j(), in sequence, as shown below. If any of those fail with a "foo" or "bar" error, f() is to handle the error immediately then return successfully. If any other error occurs, f() is to propagate the error information back to the caller.

Here is the code if exceptions are used:

The "good" path and the "bad" path are cleanly separated. The "good" (or "happy") path is the body of the try block — you can read that linearly, and if there are no errors, control flows in a simplistic path through those lines. The "bad" path is the body of the catch block and the body of any matching catch blocks in any caller.

Using return codes instead of exception clutters this to the point where it is difficult to see the relatively simple algorithm. The "good" ("happy") and "bad" paths are hopelessly intermixed:

By intermixing the good/happy path with the bad/error path, it's harder to see what the code is supposed to do. Contrast that with the version that used exceptions, which is almost self-documenting — the basic functionality is very obvious.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

Wrong:

• Exception handling is not a free lunch. It requires discipline and rigor. To understand those disciplines, you really should read the rest of the FAQ and/or one of the excellent books on the subject.
• Exception handling is not a panacea. If you work with a team that is sloppy and undisciplined, your team will likely have problems no matter whether they use exceptions or return codes. Incompetent carpenters do bad work even if they use a good hammer.
• Exception handling is not one-size-fits-all. Even when you have decided to use exceptions rather than return codes, that doesn't mean you use them for everything. This is part of the discipline: you need to know when a condition should be reported via return-code and when it should be reported via an exception.
• Exception handling is a convenient whipping boy. If you work with people who blame their tools, beware of suggesting exceptions (or anything else that is new, for that matter). People whose ego is so fragile that they need to blame someone or something else for their screw-ups will invariably blame whatever "new" technology was used. Of course, ideally you will work with people who are emotionally capable of learning and growing: with them, you can make all sorts of suggestions, because those sorts of people will find a way to make it work, and you'll have fun in the process.

Fortunately there is plenty of wisdom and insight on the proper use of exceptions. Exception handling is not new. The industry as a whole has seen many millions of lines of code and many person-centuries of effort using exceptions. The jury has returned its verdict: exceptions can be used properly, and when they are used properly, they improve code.

Learn how.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

Absolutely you might be the problem!

The C++ exception handling mechanism can be powerful and useful, but if you use it with the wrong mindset, the result can be a mess. If you're getting bad results, for instance, if your code seems unnecessarily convoluted or overly cluttered with try blocks, you might be suffering from a "wrong mindset." This FAQ gives you a list of some of those wrong mindsets.

Warning: do not be simplistic about these "wrong mindsets." They are guidelines and ways of thinking, not hard and fast rules. Sometimes you will do the exact opposite of what they recommend — do not write me about some situation that is an exception (no pun intended) to one or more of them — I guarantee that there are exceptions. That's not the point.

Here are some "wrong exception-handling mindsets" in no apparent order:

• The return-codes mindset: This causes programmers to clutter their code with gobs of try blocks. Basically they think of a throw as a glorified return code, and a try/catch as a glorified "if the return code indicates an error" test, and they put one of these try blocks around just about every function that can throw.
• The Java mindset: In Java, non-memory resources are reclaimed via explicit try/finally blocks. When this mindset is used in C++, it results in a large number of unnecessary try blocks, which, compared with RAII, clutters the code and makes the logic harder to follow. Essentially the code swaps back and forth between the "good path" and the "bad path" (the latter meaning the path taken during an exception). With RAII, the code is mostly optimistic — it's all the "good path," and the cleanup code is buried in destructors of the resource-owning objects. This also helps reduce the cost of code reviews and unit-testing, since these "resource-owning objects" can be validated in isolation (with explicit try/catch blocks, each copy must be unit-tested and inspected individually; they cannot be handled as a group).
• Organizing the exception classes around the physical thrower rather than the logical reason for the throw: For example, in a banking app, suppose any of five subsystems might throw an exception when the customer has insufficient funds. The right approach is to throw an exception representing the reason for the throw, e.g., an "insufficient funds exception"; the wrong mindset is for each subsystem to throw a subsystem-specific exception. For example, the Foo subsystem might throw objects of class FooException, the Bar subsystem might throw objects of class BarException, etc. This often leads to extra try/catch blocks, e.g., to catch a FooException, repackage it into a BarException, then throw the latter. In general, exception classes should represent the problem, not the chunk of code that noticed the problem.
• Using the bits / data within an exception object to differentiate different categories of errors: Suppose the Foo subsystem in our banking app throws exceptions for bad account numbers, for attempting to liquidate an illiquid asset, and for insufficient funds. When these three logically distinct kinds of errors are represented by the same exception class, the catchers need to say if to figure out what the problem really was. If your code wants to handle only bad account numbers, you need to catch the master exception class, then use if to determine whether it is one you really want to handle, and if not, to rethrow it. In general, the preferred approach is for the error condition's logical category to get encoded into the type of the exception object, not into the data of the exception object.
• Designing exception classes on a subsystem by subsystem basis: In the bad old days, the specific meaning of any given return-code was local to a given function or API. Just because one function uses the return-code of 3 to mean "success," it was still perfectly acceptable for another function to use 3 to mean something entirely different, e.g., "failed due to out of memory." Consistency has always been preferred, but often that didn't happen because it didn't need to happen. People coming with that mentality often treat C++ exception-handling the same way: they assume exception classes can be localized to a subsystem. That causes no end of grief, e.g., lots of extra try blocks to catch then throw a repackaged variant of the same exception. In large systems, exception hierarchies must be designed with a system-wide mindset. Exception classes cross subsystem boundaries — they are part of the intellectual glue that holds the architecture together.
• Use of raw (as opposed to smart) pointers: This is actually just a special case of non-RAII coding, but I'm calling it out because it is so common. The result of using raw pointers is, as above, lots of extra try/catch blocks whose only purpose in life is to delete an object then re-throw the exception.
• Confusing logical errors with runtime situations: For example, suppose you have a function f(Foo* p) that must never be called with the NULL pointer. However you discover that somebody somewhere is sometimes passing a NULL pointer anyway. There are two possibilities: either they are passing NULL because they got bad data from an external user (for example, the user forgot to fill in a field and that ultimately resulted in a NULL pointer) or they just plain made a mistake in their own code. In the former case, you should throw an exception since it is a runtime situation (i.e., something you can't detect by a careful code-review; it is not a bug). In the latter case, you should definitely fix the bug in the caller's code. You can still add some code to write a message in the log-file if it ever happens again, and you can even throw an exception if it ever happens again, but you must not merely change the code within f(Foo* p); you must, must, MUST fix the code in the caller(s) of f(Foo* p).

There are other "wrong exception-handling mindsets," but hopefully those will help you out. And remember: don't take those as hard and fast rules. They are guidelines, and there are exceptions to each.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

You might have the mindset of return codes even though you are using the syntax of try/catch/throw. For instance, you might put a try block around just about every call:

Although this uses the try/catch/throw syntax, the overall structure is very similar to the way things are done with return codes, and the consequent software development/test/maintenance costs are basically the same as they were for return codes. In other words, this approach doesn't buy you much over using return codes. In general, it is bad form.

One way out is to ask yourself this question for each try block: "Why am I using a try block here?" There are several possible answers:

• Your answer might be, "So I can actually handle the exception. My catch clause deals with the error and continues execution without throwing any additional exceptions. My caller never knows that the exception occurred. My catch clause does not throw any exceptions and it does not return any error-codes." In that case, you leave the try block as-is — it is probably good.
• Your answer might be, "So I can have a catch clause that does blah blah blah, after which I will rethrow the exception." In this case, consider changing the try block into an object whose destructor does blah blah blah. For instance, if you have a try block whose catch clause closes a file then rethrows the exception, consider replacing the whole thing with a File object whose destructor closes the file. This is commonly called RAII.
• Your answer might be, "So I can repackage the exception: I catch a XyzException, extract the details, then throw a PqrException." When that happens, consider a better hierarchy of exception objects that doesn't require this catch/repackage/rethrow idea. This often involves broadening the meaning of XyzException, though obviously you shouldn't go too far.
• There are other answers as well, but the above are some common ones that I've seen.

Main point is to ask "Why?". If you discover the reason you're doing it, you might find that there are better ways to achieve your goal.

Having said all this, there are, unfortunately, some people who have the return-code-mindset burned so deeply into their psyche that they just can't seem to see any alternatives. If that is you, there is still hope: get a mentor. If you see it done right, you'll probably get it. Style is sometimes caught, not just taught.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

Throw an exception.

Constructors don't have a return type, so it's not possible to use return codes. The best way to signal constructor failure is therefore to throw an exception. If you don't have the option of using exceptions, the "least bad" work-around is to put the object into a "zombie" state by setting an internal status bit so the object acts sort of like it's dead even though it is technically still alive.

The idea of a "zombie" object has a lot of down-side. You need to add a query ("inspector") member function to check this "zombie" bit so users of your class can find out if their object is truly alive, or if it's a zombie (i.e., a "living dead" object), and just about every place you construct one of your objects (including within a larger object or an array of objects) you need to check that status flag via an if statement. You'll also want to add an if to your other member functions: if the object is a zombie, do a no-op or perhaps something more obnoxious.

In practice the "zombie" thing gets pretty ugly. Certainly you should prefer exceptions over zombie objects, but if you do not have the option of using exceptions, zombie objects might be the "least bad" alternative.

Note: if a constructor finishes by throwing an exception, the memory associated with the object itself is cleaned up — there is no memory leak. For example:

There is some fine print on this topic, so you need to keep reading. Specifically you need to know how to prevent memory leaks if the constructor itself allocates memory, and you also need to be aware of what happens if you use "placement" new rather than the ordinary new used in the sample code above.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

Write a message to a log-file. Or call Aunt Tilda. But do not throw an exception!

Here's why (buckle your seat-belts):

The C++ rule is that you must never throw an exception from a destructor that is being called during the "stack unwinding" process of another exception. For example, if someone says throw Foo(), the stack will be unwound so all the stack frames between the throw Foo() and the } catch (Foo e) { will get popped. This is called stack unwinding.

During stack unwinding, all the local objects in all those stack frames are destructed. If one of those destructors throws an exception (say it throws a Bar object), the C++ runtime system is in a no-win situation: should it ignore the Bar and end up in the } catch (Foo e) { where it was originally headed? Should it ignore the Foo and look for a } catch (Bar e) { handler? There is no good answer — either choice loses information.

So the C++ language guarantees that it will call terminate() at this point, and terminate() kills the process. Bang you're dead.

The easy way to prevent this is never throw an exception from a destructor. But if you really want to be clever, you can say never throw an exception from a destructor while processing another exception. But in this second case, you're in a difficult situation: the destructor itself needs code to handle both throwing an exception and doing "something else", and the caller has no guarantees as to what might happen when the destructor detects an error (it might throw an exception, it might do "something else"). So the whole solution is harder to write. So the easy thing to do is always do "something else". That is, never throw an exception from a destructor.

Of course the word never should be "in quotes" since there is always some situation somewhere where the rule won't hold. But certainly at least 99% of the time this is a good rule of thumb.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

Every data member inside your object should clean up its own mess.

If a constructor throws an exception, the object's destructor is not run. If your object has already done something that needs to be undone (such as allocating some memory, opening a file, or locking a semaphore), this "stuff that needs to be undone" must be remembered by a data member inside the object.

For example, rather than allocating memory into a raw Fred* data member, put the allocated memory into a "smart pointer" member object, and the destructor of this smart pointer will delete the Fred object when the smart pointer dies. The template std::auto_ptr is an example of such as "smart pointer." You can also write your own reference counting smart pointer. You can also use smart pointers to "point" to disk records or objects on other machines.

By the way, if you think your Fred class is going to be allocated into a smart pointer, be nice to your users and create a typedef within your Fred class:

That typedef simplifies the syntax of all the code that uses your objects: your users can say Fred::Ptr instead of std::auto_ptr<Fred>:

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

If what you really want to do is work with strings, don't use an array of char in the first place, since arrays are evil. Instead use an object of some string-like class.

For example, suppose you want to get a copy of a string, fiddle with the copy, then append another string to the end of the fiddled copy. The array-of-char approach would look something like this:

Using char*s like this is tedious and error prone. Why not just use an object of some string class? Your compiler probably supplies a string-like class, and it's probably just as fast and certainly it's a lot simpler and safer than the char* code that you would have to write yourself. For example, if you're using the std::string class from the standardization committee, your code might look something like this:

The char* version requires you to write around three times more code than you would have to write with the std::string version. Most of the savings came from std::string's automatic memory management: in the std::string version, we didn't need to write any code...

• to reallocate memory when we grow the string.
• to delete[] anything at the end of the function.
• to catch and re-throw any exceptions.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

C++, unlike just about every other language with exceptions, is very accomodating when it comes to what you can throw. In fact, you can throw anything you like. That begs the question then, what should you throw?

Generally, it's best to throw objects, not built-ins. If possible, you should throw instances of classes that derive (ultimately) from the std::exception class. By making your exception class inherit (ultimately) from the standard exception base-class, you are making life easier for your users (they have the option of catching most things via std::exception), plus you are probably providing them with more information (such as the fact that your particular exception might be a refinement of std::runtime_error or whatever).

The most common practice is to throw a temporary:

Here, a temporary of type MyException is created and thrown. Class MyException inherits from class std::runtime_error which (ultimately) inherits from class std::exception.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

In keeping with the C++ tradition of "there's more than one way to do that" (translation: "give programmers options and tradeoffs so they can decide what's best for them in their situation"), C++ allows you a variety of options for catching.

• You can catch by value.
• You can catch by reference.
• You can catch by pointer.

In fact, you have all the flexibility that you have in declaring function parameters, and the rules for whether a particular exception matches (i.e., will be caught by) a particular catch clause are almost exactly the same as the rules for parameter compatibility when calling a function.

Given all this flexibility, how do you decide what to catch? Simple: unless there's a good reason not to, catch by reference. Avoid catching by value, since that causes a copy to be made and the copy can have different behavior from what was thrown. Only under very special circumstances should you catch by pointer.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

Depends. If you're using MFC and catching one of their exceptions, by all means, do it their way. Same goes for any framework: when in Rome, do as the Romans. Don't try to force a framework into your way of thinking, even if "your" way of thinking is "better." If you decide to use a framework, embrace its way of thinking — use the idioms that its authors expected you to use.

But if you're creating your own framework and/or a piece of the system that does not directly depend on MFC, then don't catch by pointer just because MFC does it that way. When you're not in Rome, you don't necessarily do as the Romans. In this case, you should not. Libraries like MFC predated the standardization of exception handling in the C++ language, and some of these libraries use a backwards-compatible form of exception handling that requires (or at least encourages) you to catch by pointer.

The problem with catching by pointer is that it's not clear who (if anyone) is responsible for deleting the pointed-to object. For example, consider the following:

There are three basic problems here:

1. It might be tough to decide whether to delete p within the catch clause. For example, if object x is inaccessible to the scope of the catch clause, such as when it's buried in the private part of some class or is static within some other compilation unit, it might be tough to figure out what to do.
2. If you solve the first problem by consistently using new in the throw (and therefore consistently using delete in the catch), then exceptions always use the heap which can cause problems when the exception was thrown because the system was running low on memory.
3. If you solve the first problem by consistently not using new in the throw (and therefore consistently not using delete in the catch), then you probably won't be able to allocate your exception objects as locals (since then they might get destructed too early), in which case you'll have to worry about thread-safety, locks, semaphores, etc. (static objects are not intrinsically thread-safe).

This isn't to say it's not possible to work through these issues. The point is simply this: if you catch by reference rather than by pointer, life is easier. Why make life hard when you don't have to?

The moral: avoid throwing pointer expressions, and avoid catching by pointer, unless you're using an existing library that "wants" you to do so.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

You might see code that looks something like this:

In this example, the statement throw; means "re-throw the current exception." Here, a function caught an exception (by non-const reference), modified the exception (by adding information to it), and then re-threw the exception. This idiom can be used to implement a simple form of stack-trace, by adding appropriate catch clauses in the important functions of your program.

Another re-throwing idiom is the "exception dispatcher":

This idiom allows a single function (handleException()) to be re-used to handle exceptions in a number of other functions.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

Sometimes people write code like:

If you try this, you might be surprised at run-time when your catch (...) clause is entered, and not your catch (MyExceptionDerived&) clause. This happens because you didn't throw polymorphically. In function f(), the statement throw e; throws an object with the same type as the static type of the expression e. In other words, it throws an instance of MyExceptionBase. The throw statement behaves as-if the thrown object is copied, as opposed to making a "virtual copy".

Fortunately it's relatively easy to correct:

Note that the throw statement has been moved into a virtual function. The statement e.raise() will exhibit polymorphic behavior, since raise() is declared virtual and e was passed by reference. As before, the thrown object will be of the static type of the argument in the throw statement, but within MyExceptionDerived::raise(), that static type is MyExceptionDerived, not MyExceptionBase.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

Depends. Might be "zero."

Objects that are thrown must have a publicly accessible copy-constructor. The compiler is allowed to generate code that copies the thrown object any number of times, including zero. However even if the compiler never actually copies the thrown object, it must make sure the exception class's copy constructor exists and is accessible.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

 E-mail the author
[ C++ FAQ | Table of contents | Subject index | About the author | © | Download your own copy ]
Revised Jun 26, 2011