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-25 01:09:19

Emil Dotchevski wrote:

<...>
> 
> That's my point, you want some exceptions emitted by the throw
> expression to be ignored, and some not.   <..>

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. Of course it would be nice to know why both of them happened,
but here you must chose - either you know what went wrong in the main
program, or what went wrong in error_info.

When I write this:

throw WidgetAllocError();

It's pretty obvious what I want.
Of course, it would be nice to have more informative description, that's
why I would normally add:

throw WidgetAllocError() << WidgetErrorDescription(strWidgetName);

But this now changes the original intent. By the time we reach the throw
statement, we've made a decision that an error condition has been
reached and we want to indicate that error. If we continue propagating
WidgetAllocError(), then we'll at least know what kind of error
happened, albeit without extra information. If we let error_info
throw, then we'll get most probably an unrelated error (like
  std::bad_alloc) which doesn't tell you anything about the context of
the original main error. I think that std::exception's constructor is
a no-throw exactly for this reason - once you've made your decision to
indicate an error you're guaranteed that error's propagation.
I think it's similar to a requirement that destructors don't throw.
Once someone threw an exception, then even if something goes wrong
in a destructor, we shouldn't throw new exception.

> 
>> 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?
> 
> In my mind, the postcondition of throw foo() << info1(...) <<
> info2(...) is that a foo exception containing info1 and info2 is
> thrown. If that postcondition can not be satisfied, I do want
> (another) exception that tells me why.
I understand. But you have to choose. Don't you want to know that foo()
was thrown in the first place? Because you won't know that if you throw
another exception.

Regards,
     Andy.