Re: [boost] [inspect] exceptions (FW: [Boost-users] no exceptions)

Subject: Re: [boost] [inspect] exceptions (FW: [Boost-users] no exceptions)
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2011-03-24 14:27:23

On Thu, Mar 24, 2011 at 9:34 AM, Dave Abrahams <dave_at_[hidden]> wrote:
> At Wed, 23 Mar 2011 14:29:20 -0700,
> Emil Dotchevski wrote:
>>
>> On Wed, Mar 23, 2011 at 1:47 PM, Gruenke, Matt <mgruenke_at_[hidden]> wrote:
>> > Whatever arguments there are for using BOOST_THROW_EXCEPTION()
>> > vs. throw, that seems a somewhat independent matter.  Simply making
>> > this substitution does not guarantee that the library will work properly
>> > with exceptions disabled,
>>
>> It is not independent matter because that is exactly what
>> BOOST_THROW_EXCEPTION guarantees, except when the library contains
>> try..catch or rethrows using throw without arguments, which are rare
>> cases. I agree that going the extra mile to workaround those
>> additional cases is usually unreasonable.
>
> I suppose that might be true, depending on your definition of "work
> properly."  There's no such thing as "working properly without
> exceptions" if the library was coded for use with exceptions and you
> really need a recoverable response to, say, resource exhaustion.

Yes, if the program needs recoverable response, then
BOOST_THROW_EXCEPTION is not going to work, and it is not at all
desirable to require that libraries provide an alternative mechanism.
However, this also means that BOOST_THROW_EXCEPTION will work just
fine in other scenarios:

1) When the program can deterministically avoid using operations that
throw. Example: using weak_ptr::lock instead of directly constructing
a shared_ptr from weak_ptr (which may throw.)

2) When abort() is a reasonable response to failure. Example: in video
games, it is typically OK to abort on file open or read failure, on
failure to initialize the graphics system, etc.

> That said, "libraries should generally use BOOST_THROW_EXCEPTION" is a
> good rule for Boost, and I wouldn't mind having something like it in
> the inspect tests, provided that libraries with a legitimate reason
> not to use it can be registered as exceptions to the rule.

Maybe I'm missing something but what is an example of such a legitimate reason?

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