From: David Abrahams (abrahams_at_[hidden])
Date: 2001-04-11 07:35:49
I tend to agree with Jesse here. If somebody wants the throwing behavior
(s)he can always add it atop the other one. If not, there is no recourse.
----- Original Message -----
From: "Jesse Jones" <jesjones_at_[hidden]>
To: "Peter Dimov" <pdimov_at_[hidden]>; <boost_at_[hidden]>
Sent: Tuesday, April 10, 2001 7:55 PM
Subject: Re: [boost] any_function (callback) library
> 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
> >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
> >> flow.
> >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.
> -- Jesse
> To unsubscribe, send email to: <mailto:boost-unsubscribe_at_[hidden]>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk