From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-07-21 11:06:22
Russell Hind wrote:
> David Abrahams wrote:
>>
>> Well, that's not my philosophy FWIW. Mine is:
>>
>> if the condition is a programmer error, use assert
>> otherwise, use a well-documented exception
>>
>
> So can I draw you back to the original question of why a locked
> scoped_lock throws rather than asserts? The only thing that can cause
> this is calling lock on it twice which is a programming error, isn't
> it?
It's not that simple. Whether something is a programming error is determined
by the library's specification, not vice versa. In other words, under the
current specification, re-locking a locked lock :-) is not an error, as it
is well defined. It is not a just an implementation question of using assert
or throw, it is a design question.
To decide whether double lock/double unlock should be a programming error,
you need to analyze the common scenarios where .lock() and .unlock() are
used. If you often see the recurring pattern of
if(l.locked()) return;
l.lock();
for example, this is an indication that throwing an exception is more
appropriate. If, on the other hand, client code _typically_ looks like
assert(!l.locked());
l.lock();
then it might be better to go the 'undefined behavior' route (which implies
an assert in the library, at least in debug mode.)