Re: [boost] [Review] optional exceptions

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-02-12 11:10:11

David Abrahams wrote:
> Tobias Schwinger <tschwinger_at_[hidden]> writes:
> 
> 
>>David Abrahams wrote:
>>
>>>Tobias Schwinger <tschwinger_at_[hidden]> writes:
>>>
>>>
>>>
>>>>Still, your "#ifdef suggestion" seems much worse to me -- it might
>>>>have been just provocative rhetoric rather than a serious proposal,
>>>>I
>>>>guess...
>>>
>>>
>>>No, it was serious.  But if you don't like #ifdefs there are two
>>>other proposals on the table that address the problem without using
>>>them.
>>>
>>
>>I have nothing against #ifdefs in general and it has nothing to do
>>with personal taste:
>> 
>>#ifdeffing (what a wonderful neologism) an interface means: client
>>code that wants to work regardless of whether the macro is defined or
>>not requires #ifdefs as well.
> 
> 
> 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?

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.

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.

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

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

Regards,

Tobias