Re: [boost] any_function (callback) library

From: Jesse Jones (jesjones_at_[hidden])
Date: 2001-04-10 07:47:58

At 1:19 PM +0300 4/10/01, Peter Dimov wrote:
>From: "Jesse Jones" <jesjones_at_[hidden]>
>
>>  At 12:02 AM +0300 4/10/01, Peter Dimov wrote:
>>  >From: "Jesse Jones" <jesjones_at_[hidden]>
>>  >
>>  >>  6) Trying to invoke an empty function seems like a precondition
>>  >>  violation to me. Asserting instead of throwing seems preferable.
>>  >
>>  >I agree with most of your points, however invoking an empty function must
>>  >throw for boost::function<T&> to be default constructable. (What would
>you
>>  >return from op() if it didn't throw?)
>>
>>  There's no need to return anything. The client failed to meet his
>>  obligations so the function can do anything it likes. In this case it
>>  will crash on most OSs. But that's OK. :-)
>
>But you need to return something for the code to compile.
>
>Returning *(T*)0 is not a good practice. :-)

You return the result of calling a nil function pointer. This will 
crash on a decent OS, but that's hardly unusual for precondition 
violations.

>I think that the exception-throwing version can be quite useful.

Why? This seems like an obvious precondition to me. We tell clients 
not to invoke empty function objects. If they don't then we can do 
whatever we want. In a debug build we should assert. In release 
precondition violations should never happen, but of course they will 
since testing is never perfect. The desired behavior is dependant on 
the app, but few will want to throw on every violation. I have zero 
problems with crashing in these cases. (Although as I've mentioned 
before I'd prefer a customizable assert macro).

>
>FWIW, my own implementation first returned a default-constructed
>return_type, then I thought about changing it to a precondition violation,
>but in the end I decided in favor of the exception-throwing semantics. Why
>litter the code with
>
>if(f) f();

1) It parallels what you would do with an ordinary function pointer. 
2) Why call a function if it's empty? Exceptions should be used for 
errors. This smells too much like using exceptions to control program 
flow.

   -- Jesse