Re: Exceptions as smart pointers
on Tue Aug 26 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?
struct File
{
// ...
~File(bool unwinding)
{
if (int err = close(this->x))
{
if (!unwinding)
throw couldnt_close(this->x, err);
}
}
os_file_handle x;
}
void rollback()
{
if ( logging_enabled)
{
File f(log);
f << "rolling_back\n";
}
// ...further rollback actions...
}
void f()
{
try
{
// ...
}
catch(...)
{
rollback();
raise;
}
}
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.
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 ;-)
If the exception is never caught, off to terminate you go,
potentially without any unwinding.
Time to give your definition of "safe," then ;-)
Let's put it another way: if in_stack_unwinding==true then it's UNSAFE
to throw exceptions.
Okay, but that doesn't help me. I'm going to throw exceptions from
dtors, you need to know the converse: if it's UNSAFE to throw
exceptions, in_stack_unwinding==true. uncaught_exception doesen't tell
you that, and neither does your idea, AFAICT.
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.
Okay. I *think* the cost of copying exceptions should not be a major
concern. Have you profiled?
I agree, no need to profile :)
But it's always _safe_ to copy sh_ptr<Exception>() object: we have
nothrow guarantee here.
Yes, that is a compelling argument.
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?
Non-trivial Exception classes tend to be unsafe.
So it really makes sense to use sh_ptr<Exception> object rather than
fight all of the dirty details (of nothrow guarantee).
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.
3. It's really easy to create the chains of the nested Exception
objects.
Okay.
And it was the root of the problem!
Which problem?
At the time, I tried to get portable and easy-to-use C++ exception
traces that somehow resemble my Java code. The direct solution is
sh_ptr<Exception>...
Is that the problem you're solving, then?
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?
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.
--
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! ]