Re: when does exception destructor fire
* andrew_nuss@yahoo.com:
Lets say we define a class to be used as an exception. Should it
extend std::exception or not?
Depends whether it's intended to be caught by code that catches
std::exception, or not.
There are (as far as I know) three possible conventions for
differentiating between "hard" and "soft" exceptions, where the hard
ones are the ones that should always cause termination, i.e. should
always be rethrown if caught, always propagated, but possibly after
cleanup. (1) std::runtime_error versus std::exception, which treats
standard exceptions such as std::bad_alloc as hard, but is almost
impossible to enforce in other than toy programs, (2) anything else
versus std::exception, which just relies on never using a generic
catch(...) without rethrowing, and otherwise only catching
std::exception and derived classes, and (3) not having any hard
exceptions, but instead always terminate directly where there could
otherwise be a choice between direct termination and hard exception,
which I think is the most common convention and is the convention you're
subscribing to if the term "hard" exception appears to be meaningless.
For conventions 2 and 3, always derive from std::runtime_error (just
ignore arguments that premature optimization is a good idea, that the
possibility of a small disaster in the middle of a great one is worth a
lot to avoid, and the like: these arguments have been made). For
convention 1, which is rather unreliable, derive from std::runtime_error
for soft exceptions and directly from std::exception or from some other
class derived from std::exception for hard exceptions.
Either way, my question concerns the
case where the exception object is responsible for holding memory and
freeing it, like the following:
class MyException {
std::string msg;
public:
MyException (char const* str) : msg(str) {}
std::string GetMsg () const { return msg; }
};
When we have code that does:
....
char temp[256];
... // fill temp with sprintf()
throw MyException(temp);
Where on the stack does thrown MyException live?
The exception object is copied, via the copy constructor, somewhere
(although the compiler is permitted to optimize away this copying).
The copy is destroyed when the exception has been handled, i.e. on exit
from a catch that doesn't rethrow.
Note: the copying means that C++ exceptions are thrown "by value". To
achieve polymorphic rethrowing of a caught and stored exception object,
e.g. for propagation through C code, you need virtual clone and throw
member functions.
When does it go out
of scope?
Conventional C++ scope is the wrong concept here. For the copy, it's a
kind of dynamic scope, not a lexical scope.
When does the destructor for MyException "fire", causing
its std::string data member to be destroyed? I mean, where does the
compiler put the exception object.
See above.
By the way, is there any harm in
GetMsg() above returning a const reference?
Yes. It forces an implementation with a string member. But the
efficiency + convenience may weight up for that. Regarding efficiency
it may be better to use some string holder class that can propagate
literals without making a dynamically allocated copy.
Hth.,
- Alf, 13.05.2007 11:20
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]