From: David Abrahams (dave_at_[hidden])
Date: 2003-07-21 09:48:33
Daniel Spangenberg <dsp_at_[hidden]> writes:
> Russell Hind schrieb:
>> Jon Biggar wrote:
>> > In the thread lock case, the throw avoids the undefined behavior
>> > entirely, since it doesn't ever do the underlying OS lock action that
>> > causes the undefined behavior.
>> Wouldn't a throw in operator -> of shared_ptr achieve the same thing?
> In this case, shared_ptr could not provide the "no throw" guarantee for
> dereferencing the pointer. This is usually an important requirement for
> smart pointers.
> My own discussion in c++-moderated with David Abrahams and others
> convinced me, that in most cases like this you have to decide the following:
> Which throw guarantees do we want/need?
> - If "no throw" is importand, use assert
> - otherwise use a well-documented exception
Well, that's not my philosophy FWIW. Mine is:
if the condition is a programmer error, use assert
otherwise, use a well-documented exception
Occasionally, due to a "no throw" requirement, you have to choose to
make certain things into programmer errors that would not otherwise
be, but those conditions should be *very rare*.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk