Boost logo

Boost Users :

Subject: Re: [Boost-users] Exception: adding diagnostic information from a dtor?
From: Michael Schuerig (michael.lists_at_[hidden])
Date: 2011-06-14 19:00:51


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?

> 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)?

Michael

-- 
Michael Schuerig
mailto:michael_at_[hidden]
http://www.schuerig.de/michael/

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net