|
Boost : |
From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-09-15 10:17:43
On Sep 13, 2007, at 2:23 PM, Howard Hinnant wrote:
> class sticky_exception
> {
> bool owns_;
> sticky_exception& operator=(const sticky_exception&);
> public:
> sticky_exception() : owns_(true) {}
> sticky_exception(sticky_exception& s) : owns_(s.owns_) {s.owns_ =
> false;}
> // sticky_exception(sticky_exception&& s) : owns_(s.owns_) {s.owns_
> = false;}
> ~sticky_exception() {if (owns_) {sticky_exception s; throw s;}}
> };
I promised to explain myself after a day or two and that time has
come. Thanks much to everyone who has responded.
sticky_exception is not my brain child. It is modeling a behavior
that someone else has proposed and I have been attempting to explore
the ramifications of that behavior in as unbiased manner as possible.
I did not want to mention the specific application because the
application in question brings with it all manner of history and
biased baggage.
The application is thread cancellation. One might want to call this
thread interruption or whatever. Thread interruption (I shall use the
term interruption as opposed to cancellation for really no good
reason) is essentially an exception. The stack gets unwound,
executing "landing pads" on the way up. Those "landing pads" in C++
are destructors and catch clauses.
There exist opinions that the exception representing this action be
"uncatchable". So my question to boost was: What will this mean to
code in general, without thinking specifically about interruption?
I have attempted to present the uncatchable exception in such a manner
that my position on it was not clear (in the hopes of receiving less
biased comments). However, now that the cat is out of the bag anyway,
my own concern centers around things like:
class A
{
public:
...
~A()
{
try
{
do something that might throw
}
catch (...)
{
log or delay the exception
}
}
};
...
void foo()
{
std::vector<A> v;
...
}
If ~A() is really not nothrow (even though it appears to be), then
std::vector is really not going to work very well in an exceptional
condition (i.e. it will leak A's). I.e. I have grave concerns over
sticky_exception myself, even if its only application is thread
interruption.
-Howard
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk