[boost] Re: [boost::thread] locks, exceptions and assertions

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-07-18 04:49:43

Russell Hind wrote:
> Daniel Frey wrote:
> 
>> Russell Hind wrote:
>>
>> I think that's not specific to locks/threads. In general, a library 
>> should *never* contain assert/exit/abort or anything else which stops 
>> the execution of a process immediately. An exception leaves the choice 
>> of how to react to the user - the library IMHO can't make a good 
>> decision as it doesn't know the context in which it is used.
>>
> 
> I disagree.  If the function is documented as having a pre-requisite 
> that the lock isn't already locked when calling lock, and vice-verase 
> for unlock, then it is a coding error and should be could be caught by 
> an assert.

Congratulations, you must be the perfect programmer :) Yes, you are 
right, it's a logic error and it needs to be fixed in the code. But 
remember we are all humans and we all make errors. In large systems you 
always have them and the example I gave is still reasonable. With 
exceptions, I can create a more robust system which is an absolute 
must-have. Our processes can handle about 1000 session simultanously, 
why should I stop all of them just because 1 session/user triggers a bug?

> mutex::scoped_lock Lock(Mutex);
>     Lock.lock();
> 
> is just plain wrong and could easily be handled by an assert.  It isn't 
> something that might go wrong at run-time and might not, this will 
> always fail and as such doesn't need an exception, IMHO.

But these two lines can be separated, encapsulated in several classes 
and being call depending on user input. I don't see why an assertion 
should be required. If you don't catch the exception, it behaves like 
assert, doesn't it? Except that it call dtors and allows the process to 
clean up :) So, what is your problem with exceptions? IMHO there is only 
one thing that might be a problem: If you need to compiler/work without 
exceptions at all, but than a call-back for the library would be 
appropriate, the default is to throw an exception but you are free to 
replace it by whatever you want. Even abort, but still it's a user's 
choice, not the library's.

Regards, Daniel

-- 
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de