From: Emil Dotchevski (emil_at_[hidden])
Date: 2008-08-20 14:15:38
On Wed, Aug 20, 2008 at 10:07 AM, Robert Ramey <ramey_at_[hidden]> wrote:
> Peter Bartlett wrote:
>> Quoting Robert Ramey <ramey_at_[hidden]>:
>> I'm not sure that is the right characterization. By default Boost
>> works with standard C++ so if RTTI is turned off, then it is fair to
>> require the BOOST_NO_TYPEID define. Changes such as this which
>> potentially change "latent" bugs in client code/setup being turned
>> into visible bugs have to be acceptable when changing Boost version,
> My complaint is the imposition of a new requirement. This changes
> the "contract" between the library and its user. You can't change
> the contract and say that the code which used the old contract
> had "latent" bugs in it.
>>> I have no idea what else this might break.
>> It will break people using throw_exception but throwing things not
>> derived from std::exception. This was an implicit requirement anyway,
> What is an "implicit requirement"? You mean that previous users
> of boost/throw_exception where remiss if they didn't derive
> from std::exception or if they didn't surround throw_exception
> with #if BOOST_NO_TYPEID. I like to think I'm a smart guy
> but I don't claim to be telepathic.
The implicit requirement was that any exception passed to
boost::throw_exception must derive from std::exception. This has
always been a requirement but it wasn't enforced before. It is
enforced now and this did catch a few violations of this requirement.
>> but users will have previously got away with it if they never actually
>> exercised their code on a no-exceptions platform.
> Hmmm - It looks to me that the previous code would work fine
> on a no-exeptions platform - all it did was call a user defined
> throw_exception function.
Which takes std::exception. That's why it is required to derive from
>> I can't think of any other problems, though. What did you have in
> LOL, That's the problem. I can't think of any problems because
> to do so would require investigating the new library in more detail
> would cost me more time than I have available right now.
The reason why the library integrates with boost::throw_exception is
to allow the user to take advantage of the new facilities without
requiring changes in any library that throws exceptions.
Granted, for something as central as throw_exception, this has to be
done very carefully and I think your concern is that this wasn't the
case. Note that we don't have test failures in any library due to this
new behavior of boost::throw_exception.
Of course, if you can think of any problems or potential problems I'm
very much interested to know about them.
> This was not a problem then throw_exception had a very limited and
> well defined purpose. The real problem is
> creating a new library with new functionality and requirements
> and assigning to an old name which heretofore was being used
> for something else. This kind of thing creates a lot of unnecessary
> work for innocent bystanders.
I'll ignore the unsubstantiated claims and I'll just point out that
boost::throw_exception has the same purpose it did before: it throws
the exception you pass to it. The only difference is that now any
exception that emanates from Boost can be transported between threads
and can transport any data to the catch site.
Consider that without the new boost::throw_exception behavior, for a
user to take advantage of the new Exception library, it would be
required to change all Boost libraries that throw exceptions.
>> IMO, the major issue with this change is the lack of documentation.
>> seems to refer to the 1.35 version of the code. I don't know if this a
>> documentation bug or a documentation generation bug.
> well, there is that as well.
The function is well documented, see
Even if the new documentation was not available, the old documentation
is 100% accurate because the semantics of boost::throw_exception have
not changed at all.
Reverge Studios, Inc.