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);
> 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.
-- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk