Re: [boost] Boost and exceptions

Subject: Re: [boost] Boost and exceptions
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-06-20 15:23:09

On Tue, Jun 19, 2012 at 6:33 PM, Robert Ramey <ramey_at_[hidden]> wrote:

> Jeffrey Lee Hellrung, Jr. wrote:
> > On Tue, Jun 19, 2012 at 3:51 PM, Robert Ramey <ramey_at_[hidden]> wrote:
> > [...]
> >
> >> And of course I'm still smarting from having the BOOST_NO_EXCEPTIONS
> >> definition change while I wasn't looking to from what has always been
> >> documented in a way that makes some sense to something that
> >> I still dont' get.
> >>
> >> So I stand behind my suggestions.
> >>
> >
> > Sorry, I've only been glossing over this discussion. Can someone
> > please clarify how BOOST_NO_EXCEPTIONS has changed,
>
> Just look higher in the the thread for Emil's definition of
> BOOST_NO_EXCEPTIONS.
> This is different than the one in the documentation which has never changed
> and in fact is part of another library.  This situation has lead to much
> confusion as to what this macro means as noted higher in the thread.
>
> >what specific
> > change Robert (and possibly others) find troubling, and what
> > practical consequences this has had or presently has?
>
> Well, it's left me confused about what it's supposed to be.
>

Okay, Boost.Config says about BOOST_NO_EXCEPTIONS that

"The compiler does not support exception handling...Note that there is no
requirement for boost libraries to honor this configuration setting"

while Boost.Exception says

"This macro disables exception handling in Boost, forwarding all exceptions
to a user-defined non-template version of
boost::throw_exception<http://www.boost.org/doc/libs/1_49_0/libs/exception/doc/throw_exception.html>
."

Is the confusion primarily that there are two descriptions of
BOOST_NO_EXCEPTIONS? I certainly find this confusing, and it would be great
if these descriptions can be brought more in line with one another.

Is the confusion whether this applies to a property of the compiler (as
Boost.Config suggests), or whether it is a user-defined setting (as one may
infer from Boost.Exception's description)? From a library's point-of-view,
I don't see any practical difference; if a library wants to support a
defined BOOST_NO_EXCEPTIONS in either case, it can't have any exception
handling code.

Is the confusion whether respecting the disabling of exception handling is
optional within a given library (as stated by Boost.Config) or mandatory,
with any exceptions going to boost::throw_exception (as one may infer from
Boost.Exception's description)? Except for the apparent requirement implied
by Boost.Exception that all libraries will "throw" exceptions through
boost::throw_exception when BOOST_NO_EXCEPTIONS is defined, these don't
seem incompatible. If a library uses boost::throw_exception to "throw"
exceptions, it likely will do so consistently, so will automatically
support disabling exception handling. On the other hand, if it doesn't,
well, it either doesn't support the disabling of exception handling or it
uses its own mechanisms to deal with "exceptional" situations. I presume
some libraries may take the latter approach? Meaning the assertion that all
exceptions are forwarded to boost::throw_exception is inaccurate?

> Ditto for  boost::throw_exception.
>
> Ahhh - a somewhat different case.  boost throw exception as implemented
> in a very simple way for a very simple purpose.  That purpose was to
> provide
> and escape to a global function which one could implement for those
> platoforms
> which failed to implement exceptions.  This is not so uncommon for embedded
> systems and some shops which prohibit usage of exceptions.
>

Okay, I'm following.

> The function of this was changed with the inclusion of boost.exception
> which
> altered the purpose and implementation of boost::exception in include the
> functionality of boost.exeption.  You should be able to guess what
> happened.
> All the librarires which has presumed the original operation started to
> have
> changed behavior.

Okay, so I infer that, "before", "boost::throw_exception(e);" was
equivalent to "throw e;"; "now", it is equivalent to "throw
enable_current_exception(enable_error_info(e));". enable_error_info ensures
the thrown object derives from boost::exception, while
enable_current_exception "enables exception_ptr support". Okay, I admit,
it's been a while since I've read the Boost.Exception docs and I forgot
what that "exception_ptr support" means, but I think the point is that the
actual thrown object is different "now" from "before". Although I think the
idea was that the new thrown object still inherited publicly from the
original object, so catch blocks should still function as before.

 Longer build time, dependence on a new library, new
> requirement that the library be only used with rtti turned on.

At this point, based on Emil's and John's responses, it seems these first 2
issues aren't really problems in practice, while the 3rd issue is simply
not the case.

 For some
> unfathonable reason, the change in boost::throw_exception was allowed to
> stand.  So these libraries including serialization, boost.filesystem, and
> some
> others had to creat their own macros to implement the behavior of the
> original boost::throw_exception.

Was actual code broken due to the change, and, if so, do you remember any
examples? Or were those libraries authors who reimplemented the original
functionality simply concerned with the overhead introduced by
boost::throw_exception?

 So now we have the case where
>
> a) the original functionality is not found in boost, anyone who needs
> it has to implement it on their own.
> b) the same functionality is re-implemented in several other libraries
> which required a new round of updating of code a documentation,
> c) and now we have the situation where a user who invokes something
> in the core boost - boost::throw_exception is likely to get a lot more than
> he bargained for.

> Basically, if one want's the functionality of boost exeception, he should
>
> #include <boost/exception/thow_exception.hpp>
> ..
> boost::exception::throw_exception
>
> and if he want's the original behavior he should be able to say
>
> #include <boost/throw_exception.hpp>
> ...
> boost::throw_exception.
>
> gratuitiously changing the behavior of a long standing function in the
> boost core which other library depend on is an unfriendly practice.
> I know Emil is convinced that he's done us a big favor by forcing
> us to convert to behavior which he knows is better for us, But it's
> not his call to make.  It's not for me to go around chaning the
> behavior of other peoples libraries just because I know better.
>

Okay, fair enough; this is an understandable but more philosophical point
concerning development practices. At this point, though,
boost::throw_exception has had these semantics since...well whenever
Boost.Exception was released, which appears to be 1.36 based on my changing
the version number in the URL of the documentation of
boost::throw_exception :/ And it seems like changing it *back* to the
pre-1.36 functionality would break more code than the change introduced in
1.36.

> (For the record, I've glanced at the blurbs on BOOST_NO_EXCEPTIONS
> > within Boost.Config and Boost.Exception and it's difficult for me to
> > parse what effect their differences have in practice, and it sounds
> > like others have a good idea what the problem seems to be.)
>
> I hope I clarified this.
>

Clearly not entirely :)

- Jeff