Re: [Boost-users] Exception: adding diagnostic information from a dtor?

Subject: Re: [Boost-users] Exception: adding diagnostic information from a dtor?
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2011-06-14 19:38:45

On Tue, Jun 14, 2011 at 4:00 PM, Michael Schuerig
<michael.lists_at_[hidden]> wrote:
> On Wednesday 15 June 2011, Emil Dotchevski wrote:
>> Michael,
>>
>> You're right, the boost::current_exception function is only valid
>> within a try block.
>>
>> The issue you're raising has to do with the postconditions of
>> operator<<. Its current semantics guarantee that upon return the
>> error info is successfully stored in the exception object. This
>> means that when you catch an exception, you can rely on certain
>> error info to be present:
>>
>> catch( file_read_error & e )
>> {
>>     assert(get_error_info<errinfo_file_name>(e)!=0);
>>     std::cerr << "Error reading " <<
>> *get_error_info<errinfo_file_name>(e); }
>>
>> Without this guarantee, the catch site would be required to deal with
>> any exception even if it has no error info in it.
>
> Emil,
>
> thanks for your explanation. Unfortunately, I don't understand it. I do
> understand that e << errinfo_file_name(fn), if successful at all (i.e.,
> it doesn't throw itself) guarantees that the respective info is present
> in e. However, this is a dynamic property, I don't see any static reason
> why it must be true for every file_read_error. So, in principle, a catch
> site for that exception would have to take into account that this info
> might be missing. Am I missing something?

The postcondition in op<< allows the programmer to make a design
decision that any and all file_read_error exceptions reaching a
particular catch site in the program will be guaranteed to have a file
name in them, and to treat the absence of a file name as a logic error
(that is, a bug, hence the assert in my example.)

This is similar to passing something to an exception type's
constructor: it'll throw (something else) if it failed to construct,
right? The semantics of op<< simply extend this behavior to the case
when you stuff something in the exception object at a later time.

I'm not implying that it is always invalid to have optional error info
in exception objects, only that without this guarantee you couldn't
make error info non-optional.

>> If you are to add error info to exception objects in destructors,
>> this guarantee can not hold.
>
> I'm not sure I understand this either. If file_read_error can be thrown
> without initially having an errinfo_file_name and this info is only
> added during unwinding higher up the call stack, then why does it make a
> difference if it is in a catch block or in a destructor (ignoring for a
> moment that calling current_exception isn't legal there)?

You're right that it doesn't make a difference, provided that you
don't choose to treat the absence of certain error info as a bug. The
point is that if you always add error info in destructors, that choice
is not available and you must be able to deal with any exception only
knowing its type.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode