Re: Exceptions as smart pointers
on Mon Aug 25 2008, "Sergey P. Derevyago" <non-existent-AT-iobox.com> wrote:
David Abrahams wrote:
class A {
// ...
~A(bool in_stack_unwinding) {
if (in_stack_unwinding) { /* ... */ }
else { /* ... */ }
}
};
That appears to only change the interface, but not address the semantic
issues with uncaught_exception. More specifically:
under what conditions will in_stack_unwinding be true above?
Please refer to 15.2p3: The process of calling destructors for
automatic objects constructed on the path from a try block to a
throw-expression is called "stack unwinding."
I.e. in_stack_unwinding destructor argument is true if the
destructor was called during the stack unwinding. According to 15.2 if
(in_stack_unwinding) then an exception can leave the destructor
without a terminate().
Then that's still not very useful, because the dtor might be called from
inside a catch block where the programmer needs non-throwing operations,
and in_stack_unwinding would be false. A catch block where there is a
final "throw;" is often written as though it were the semantic
equivalent of a dtor; the only difference of course is what happens when
you get another exception, and most programs simply outlaw that
possibility.
If you're suggesting semantics equivalent to "is it safe to throw," I
don't _think_ that's actually implementable.
But it IS.
I don't see how. The information about what is "safe" is not encoded in
the program text; it's a function of the semantics the programmer is
trying to achieve.
Basically, it's like this: if you define "safe" to be something that can
be known by the compiler, I claim it's not a useful definition, and if
you define "safe" in a useful way, I claim it's not implementable :-)
The EH-support runtime calls a destructor with
in_stack_unwinding==true argument so this destructor does really know
whether it's safe to throw exceptions.
Time to give your definition of "safe," then ;-)
Can you give a summary of what you achieve by throwing smart pointers?
1. Smart pointers are cheap to copy and the throwing/catching
exceptions supposes copying.
Throwing requires an accessible copy ctor, but I know of at least one
implementation where you can throw an rvalue without copying it. I
don't see how catching supposes copying. But anyway...
So you can create arbitrary big Exception
objects, throw them as sh_ptr<Exception>(/* ... */) and they will be
copied almost for free.
Okay. I *think* the cost of copying exceptions should not be a major
concern. Have you profiled?
2. sh_ptr copy constructor doesn't throw exceptions so there
is no chance to get terminate() during the copying of
sh_ptr<Exception>().
Yes, that's a useful known technique.
On the contrary, Exception copy constructor does
really throw exceptions so its copying is expensive and can lead to
terminate().
Depends on what Exception is, neh?
3. It's really easy to create the chains of the nested Exception
objects.
Okay.
4. Having recatchException() function you can use the following
uniform exception handler in almost all of the places:
void f()
{
try {
// ...
g();
// ...
return;
}
catch (...) {
throw newException(_FLINE_, "Problems in f()",
recatchException(mp, _FLINE_));
}
I still don't understand what recatchException is supposed to do.
What's mp above?
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]