Re: [Boost-users] exception: use of error_info can mask real exceptions

Subject: Re: [Boost-users] exception: use of error_info can mask real exceptions
From: Andrew Venikov (andrew.venikov_at_[hidden])
Date: 2009-05-24 20:11:10

<...>
> What you want is, once you've reached a point in the program that is
> going to throw an exception, to guarantee that you will throw that
> exception and not something else.

Precisely.

> 
> The problem is that this has to extend to all failures that can occur
> within the throw expression. Such failures are not limited to
> bad_alloc; any function you call in the throw expression may throw any
> exception. I'm reasonably certain that you don't want those to be
> ignored, do you?

No, I wouldn't want those to be ignored.
Ideally, I would want to know about all failures. But if I had to
choose, I would choose to have knowledge about the original exception.
Here's my reasoning:

The original exception, one would think, indicated an error condition in
the system proper. The exception that occurred during construction of an
object describing a failure, really has nothing to do with the system
proper. It may indirectly indicate that there's something wrong with
the system, but I'm way more interested in why the original exception
happened. What if system entered an unrecoverable state due to the
original error condition? And the failure to initialize an error
description just follows from the original error? In that case getting
an exception about error descriptor's failure is not nearly as
informative as getting the original cause of the error.

Take the simplest, and in my opinion the most probable scenario.

1.The system runs out of memory trying to allocate a certain resource.
2.An exception that indicates the condition and resource is thrown.
3.We try to add a description to the exception thrown, description
   requires memory.
4. But, since we're already out of memory, we fail creating the error
    description.

What exception would you rather want to receive in this case?

For example:

AwesomeWidget * pWidget = MakeAwesomeWidget();
if (!pWidget)
{
    throw AwesomeWidgetError()
       << OwesomeWidgetDescriptor("more information here");
}

If construction of OwesomeWidgetDescriptor fails but I still get
AwesomeWidgetError(), then at least I know where and what kind of
error I encountered. There's even a good chance that error condition
was caused by allocating too many AwesomeWidgets, or leaking them.
If, on the other hand, I get an exception thrown from
OwesomeWidgetDescriptor initialization code, I will get an unrelated
exception. I will not know that the error actually happened while
trying to create an AwesomeWidget.

Andy.