Re: Exceptions as smart pointers
on Sat Aug 30 2008, "Sergey P. Derevyago" <non-existent-AT-iobox.com> wrote:
David Abrahams wrote:
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.
Could you show the code, please?
<snip my example>
I see no _additional_ problems here
Additional to what?
because File ctor can also throw just like the File dtor in question.
Assume you know the file ctor won't throw, or that it is constructed in
a different scope and moved into place, or pick any other minor
variation one needs so the dtor is the only thing that could throw
during rollback.
The point is that if in_stack_unwinding==true then an exception from
the destructor *shall* lead to terminate(). No guess, this is a strong
guarantee.
Not *that* strong ;-)
I prefer really robust solutions ;)
I understand that. I'm saying your solution doesn't seem to be as
robust as you think.
In fact, as far as I can tell, uncaught_exception() will be
true during a dtor in exactly the same cases where your enhanced dtor's
unwinding argument will be true. If I'm wrong, please demonstrate how.
Please, consider the following code:
void f()
{
A a;
throw something;
}
A::~A(bool unwinding)
{
B b;
}
In this case A's unwinding==true but B's unwinding==false.
Really? That's even less useful than uncaught_exception()'s semantics!
It's equally unsafe to throw from ~B as it is from ~A. Furthermore,
stack unwinding *will* be underway when B is destroyed, so having
unwinding==false in B's dtor is in some sense a lie.
Does uncaught_exception() have the same semantics?
No, thank goodness! The following demonstrates that throwing from ~B is
just as unsafe as throwing from ~A.
// test.cpp
#include <exception>
#include <iostream>
int const something = 5;
struct B
{
~B()
{
std::cout << "~B: " << std::uncaught_exception() << std::endl;
throw something;
}
};
struct A
{
~A()
{
std::cout << "~A: " << std::uncaught_exception() << std::endl;
B b;
}
};
void f()
{
A a;
throw something;
}
int main()
{
try
{
f();
}
catch(...)
{
std::cout << "caught" << std::endl;
}
}
$g++ test.cpp -o test && test
~A: 1
~B: 1
terminate called after throwing an instance of 'int'
/bin/bash: line 1: 24839 Aborted ./fu
Okay. I'm not sure whether I agree. What is your argument against
Pimpl exception objects that contain nothing more than a shared_ptr?
That approach at least preserves the ability to catch base classes.
It complicates the life if you need to build the nested exception
chains. The chain of sh_ptr<BaseException> objects is really easy to get
if you always throw sh_ptr<BaseException>.
Yes, but it requires everyone to cooperate in that protocol. No
environment I work in can offer an assurance that it will be the case.
shException recatchException(mem_pool& mp, const FileLine& location)
{
try { throw; }
catch (shException she) {
return she;
}
catch (const std::exception& se) {
return newStdExternException(mp, location, se.what(),
typeid(se).name());
}
catch (...) {
return newUnknExternException(mp, location, "Unknown exception");
}
}
Okay. I'm not sure why newException isn't calling recatchException
instead, but at least now I understand what you're doing.
Prefer "one class (or function), one responsibility", you know ;)
I'd be paying more attention to "Don't Repeat Yourself," in this case,
but to each his own.
--
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! ]