Dave Butenhof wrote:
Wil Evers wrote:Jason Merrill wrote:* Should cancellation also be disabled in destructors run during normal execution? In catch blocks? IMO, no and no.This implies a difference in how destructors behave, depending on why they are invoked. If such a difference can be avoided, I think it should be: we have Ted Baker's model (destructors always disable cancellation), and the other obvious choice is to leave it to the user to take the necessary precautions when writing destructors. Good C++ programmers already know how to do that.They may know how, but most haven't previously had any need to worry about that. It seems to be fairly widely agreed here that propagating an exception out of a destructor is "bad". Since that's what will happen if cancellation strikes an unprepared destructor, it seems to me that the best option is to prevent that in the default case (by disabling cancellation), and requiring any destructor that really WANTS to be cancellable to do something unusual.
IMO, the problem with Jason's model is that it only protects against *some* cases where exceptions escape from destructors:
* Jason wrote that cancellation will not be disabled when a destructor is run during normal (non-unwinding) execution. In that case - likely the most common one - a cancellation exception may be thrown, and will escape.
* Many cancellation points are I/O primitives, and I/O operations are sources of runtime errors; many C++ libraries report such errors by throwing exceptions. In other words: if we can expect a cancellation exception, we should probably expect other kinds of exceptions too. Obviously, these exceptions will also escape.
So again, if we're determined not to let exceptions escape, we need a catch-and-finalize block. It seems to me that automatically disabling cancellation while unwinding may result in a false sense of security.
- Wil