Re: [boost] Review Request: Boost Exception

From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2006-11-14 18:17:01

On 11/14/06, Emil Dotchevski <emildotchevski_at_[hidden]> wrote:
> Zach Laine wrote:
> > <snip>
> >>> It would be nice to have the actual headers linked to somewhere in
> >>> the online docs.
> >>
> >> Done. You can browse the source code, tests and everything here:
> >>
> >> http://www.revergestudios.com/boost-exception/src/
> >
> > I actually meant that the online docs that you intend to submit for
> > review would benefit from having the library's source files included
> > as well.
>
> OK I am confused. The source code is available and has been available for a
> few months now, when I did the preliminary submission, there were some
> discussions, changes in the design, etc. Starting this thread, with the
> Review Request subject line, I thought that I am submitting the library for
> official review. Did I miss something? What source files are you talking
> about?

No, I was confused.  I didn't see the "Browse the source code" at the
top of the docs.

> >>> As for the library itself, the name "exception" is fine within the
> >>> context of Boost, but it's going to collide with std::exception if
> >>> this is ever standardized.  Is there another name for this?  I have
> >>> to admit, nothing better springs to mind.
> >>
> >> Since you bring it up, please do correct me if I'm wrong but *if*
> >> this is ever standardized, it could expand the semantics of
> >> std::exception. As far as I can see, this would not break existing
> >> code because the boost::exception constructors don't allocate memory
> >> and don't throw exceptions. Besides a pointer to the internal
> >> implementation (which is the only data member of boost::exception)
> >> there is no overhead; I could not find anything in 18.6.1 that
> >> boost::exception would violate.
> >
> > That's correct, but I think a likelier scenario for standardization
> > would be to include Boost.Exception as-is, so that it a) does not
> > affect any current standard library or user code, and b) retains its
> > full usefulness (I'm thinking here of your rationale section "Why
> > doesn't boost::exception derive from std::exception?").  Anyway, this
> > isn't a major objection, just something to think about.
>
> I guess you can add "because that way it could become std::exception" to
> "why doesn't boost::exception derive from std::exception".

Well, I was specifically thinking of this sentence: "If
boost::exception derives from std::exception, this would create a
problem for enable_error_info: it is designed to make it easier to
integrate Boost Exception with existing exception class hierarchies
which can not be modified without a risk of breaking existing
exception handling code."  Standardizing boost::exception as a
separate class would be more useful with respect to
non-std::exception-based exception classes.

> >>> What is the motivation for the Logging system's string conversion
> >>> behavior #3?  It seems that a compilation failure would be
> >>> preferable in most cases, since the silent failure of #3 to convert
> >>> to a string won't be noticed until the program is completely
> >>> compiled and executed.  I'd rather know at compile time.  This
> >>> should at least be an option.
> >>
> >>  <snipped>
> >> In general, the value you store in a boost::exception could be
> >> something you can't print, but can be used to get you the thing you
> >> can print; this is beyond the scope of what().
> >
> > I agree with your point, but it would also be nice to have a strict
> > mode, so that the compiler could catch all the places that the default
> > string was going to be produced.  If I decide that I want all
> > boost::exception instances in my code to produce useful output for all
> > their contained data (a reasonable expectation for many validation
> > schemes), I have no way under the current design of doing so.
>
> When you say "useful output" you do realize that the output from what() is
> not user-friendly, right? Displaying the information relevant to a
> particular error is a separate issue beyond the scope of boost::exception.
> The user-friendly message is composed based on the type of the exception
> object, and the contained values recovered by get_error_info<>.

I don't necessarily want user-friendly output, I just want for users
who use what() to optionally be able to know for certain that all
values in what()'s output are meaningful.  In other words, some users
will consider it unsatisfactory if what() ever produces "file.cpp 64
<unknown>".  Those users that find this unsatisfactory should have a
means of preventing it.

It comes down to the fact that boost::exception::what() advertises
that it produces output for each associated datum, but currently it
silently fails to do so if I forgot to provide the correct overload of
operator<<.  Since we're dealing with exception handling here, many
times what() will be used to print out a bit of info right before an
abort.  For hard-to-reproduce exceptions, you really want all the info
you can get, and finding out that you forgot to define the right
operator<< overload at runtime is going to be really painful in many
cases.  While the increased usability of substituting "<unknown>" will
probably be preferable for most use cases, it is certainly not for
others.

> Your program
> has to "know" what values to expect in a particular exception type, and
> you're free to report missing values that are required by design.

Sorry, I don't understand this sentence.  Could you say it another way?

> > My only
> > option right now is to inspect the code or run the code, trying to
> > provoke all the exceptions.  These are error-prone ways of verifying
> > that the what() output is whatw I want, obviously.  So I'd like to see
> > something like BOOST_EXCEPTION_STRICT_WHAT, that when defined causes a
> > compile failure for behavior #3.
>
> It seems to me that your motivation with this issue is to make the output of
> what() more user-friendly, and more useful.

Not necessarily.  My main aim is to provide those users that want to
use what() to get at the data attached to an exception, and that want
to ensure all those data are actually printed, a way to get the
compiler to check for them that this is possible.

> I am all for making what() more
> useful, but at the same time I think that such efforts must not interfere
> with the ability to store *any* value type in a boost::exception.

I agree.  That's why I suggested that the strict mode be optional.

> Perhaps we can make the compiler issue a warning if you add to a
> boost::exception value type that can't be converted to string? What do you
> think?

Well, that's a possibility, but consider this:  If such a warning were
on all the time, some users would complain, since many users work
under the rule that their code must build without warnings.  So then I
think you'd probably end up defining something like the macro above
anyway, so users could see the warnings or turn them off.

Once you've got the macro, I think the users that turn on the warning
behavior would prefer an error, since the whole point of turning it on
is to catch those places in which string conversions are needed.

Zach Laine