Boost logo

Boost Users :

Subject: Re: [Boost-users] exception: use of error_info can mask realexceptions
From: Peter Dimov (pdimov_at_[hidden])
Date: 2009-05-25 08:17:04

Andrew Venikov:

> I would rather say that the main exception should be thrown no matter
> what. As I described in my previous post, the main, or original
> exception, indicates an error in the main system/logic. The exception
> thrown while trying to construct an error description is just that -
> an error to create additional description about an already occurred
> error.

An exception should never indicate a logic error, because logic errors
should never occur (and when they do, they are generally not recoverable.)

It is not clear to me why you insist that the second exception has nothing
to do with "the main system". If the main system is out of memory, it is out
of memory. It cannot just be out of memory for some secondary tasks as
creating an error description.

In the general case, I'd argue that the second exception should be treated
as more critical than the first, because the first exception can well happen
in a context where it's normal for something to fail, whereas the second
occurs in a context where it's not normal for something to fail (namely, the
error handling branch).

> It looks like we really have to decide, what's more important -
> preserving the original exception or preserving a newer exception.
> I'm trying to understand whether this dilemma simply presents a matter
> of taste, or is there a real (if a little academical) problem to solve.

It's a bit like pricing the credit default swap of, say, Germany. Germany
will never default, and if it does, the party issuing the CDS is unlikely to
be solvent and pay, so the price is random noise. Similarly, secondary
exceptions overwriting the first one (the horror) are so rare that it's not
possible to "price" the alternatives in an accurate manner (that is, to test
them in practice.)

I'd say that the only situation in which something like that can occur is
with (an equivalent of) bad_alloc "overwriting" another (equivalent of)
bad_alloc. In this case it is not clear to me why would one insist of
knowing the precise bad_alloc that was thrown since an out of memory
condition is an out of memory condition, no matter where it occurs.

You may well want to know that a certain memory pool has been exhausted, but
if you do, simply do not allocate in the error handling code from that same

Either way, given

    throw foo() << expr1 << expr2;

if you really want to reliably throw foo() and consider expr1 and expr2
optional, the way to do it is:

    foo x;

    try { x << expr1 << expr2; } catch( ... ) {}

    throw x;

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at