Re: What risk of undefined behavior if destructor must throw?
Greg Herlihy wrote:
I would go further and make sure such a class could not be used outside
of an STL container either. There is simply no good reason for a
destructor to throw exceptions. After all, the destructor's
implementation cannot know for certain what throwing the exception will
actually do, so it must be the case that whoever wrote the code for the
destructor does not know what they are doing either.
No, it is simply the case that whoever wrote the code for the destructor
doesn't know what the application is doing. Which, of course, is true
for just about any library code that throws exceptions, not just
destructors.
The right rule here, as always, is that destructors that throw
exceptions should document that. If aborting execution is not
appropriate according to the application's design, the application
implementor should not use objects of those types in contexts where that
destructor might be executed during stack unwinding.
If you're so paranoid that you won't ever write a destructor that might
throw an exception you severely limit what you can do in an application.
Most important, your destructor can't use iostreams to log errors,
because someone might have set the stream object to throw exceptions on
io errors. Maybe you could use fprintf.
--
-- Pete
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]