From: Jesse Jones (jesjones_at_[hidden])
Date: 2001-04-10 18:55:08
At 8:34 PM +0300 4/10/01, Peter Dimov wrote:
>From: "Jesse Jones" <jesjones_at_[hidden]>
>> >if(f) f();
>> 1) It parallels what you would do with an ordinary function pointer.
>> 2) Why call a function if it's empty?
>Yes, this makes sense. But introducing undefined behavior still feels
>somewhat wrong to me. Undefined behavior is usually introduced when validity
>checks (a) will have severe performance impact, or (b) are impossible.
>Neither of these applies.
The problem is that as a library author you can't determine if
checking preconditions in release is going to have a "severe
performance impact". You have no idea how sensitive the app is to
small performance hits and no idea how often clients are actually
calling your function. Throwing an exception, asserting, crashing,
no-op are all policy decisions that belong to the user. But, by and
large, they're global policies. By using an assert we provide a hook
under which we can implement these policies at a later date.
> > Exceptions should be used for
>> errors. This smells too much like using exceptions to control program
>Exceptions _are_ a control flow mechanism, no more, no less.
Well, there's a reason people disparage using exceptions to control
flow: they obfuscate the program flow and they're much more expensive
than the normal mechanisms. I've used exceptions to control flow, but
only very rarely.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk