Re: [boost] [Review] optional exceptions

From: David Abrahams (dave_at_[hidden])
Date: 2006-02-12 14:41:27

Tobias Schwinger <tschwinger_at_[hidden]> writes:

> David Abrahams wrote:
>> Tobias Schwinger <tschwinger_at_[hidden]> writes:
>> 
>> 
>>>David Abrahams wrote:
>>>
>> Client code that wants to work whether exceptions are turned on or
>> not also requires #ifdefs, no matter what you do with the interface
>> to this particular library.
>> 
>
> To ensure we understand each other correctly: a non-throwing interface
> can always be used, regardless whether exceptions are available or
> not, right?

Whoops. OK, that's right.

> A non-throwing interface may even be attractive when generally using
> exceptions in case you would enclose the initialization with a
> try-catch block, anyway.  In the particular case of this library the
> initialization is likely to happen at application start-up, so it
> isn't too difficult to imagine cases for both the RAII and the
> success-return approach to come handy.

If you get a failure at application start-up and you *don't* throw an
exception, what do you hope your application will do?  Continue
without shared memory?

> I just noticed Boost.Build supports optional exception handling (at
> least for some compilers), so the second point in my previous post
> probably isn't too much of an issue. Still -- I can't help but find it
> cleaner to have another class for RAII which simply won't be availible
> if BOOST_NO_EXCEPTIONS is defined rather than to have a class
> interface shape-shift based on compiler settings or deficiencies.

Great, that was the 2nd of my 3 suggestions for addressing this problem.

> No docmatic about exceptions from my side in any way; I believe,
> however, it's a good thing to have (at least some) libraries that
> allow to turn exceptions off -- it adds to the value of Boost because
> it welcomes users working with resource-critical execution
> environments 

Absolutely.  No argument from me.

> and AFAIK it's impossible to implement zero-overhead stack unwinding
> (you're the exception expert, so please correct me if I'm wrong).

If by "zero-overhead stack unwinding" you mean exception handling that
has no speed cost unless an exception is thrown, then consider
yourself corrected.

> BTW. I hope we're not in a flame-war ;-), are we? I also hope it
> doesn't seem like it...

No, I don't think we are.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com