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

From: Jon Biggar (jon_at_[hidden])
Date: 2003-07-18 11:46:43

Russell Hind wrote:
> Surely if they are already locked, then this is a logic error on the 
> code side.  I understand that mutex contructors and stuff throw if they 
> can't allocate the resources from the OS, as the code couldn't ensure 
> that would succeed, but if I call lock on an already locked scoped_lock, 
> then isn't that a coding error that could be caught with an assert 
> rather than an exception?

Yes it's a coding error, but changing this to an assert takes away the 
ability of a large class of applications to use the library safely.

If the library asserts, the application has *no* way to clean up safely 
before it dies.  That means that external resources that the application 
uses are left in an inconsistent/locked/lost state.  If the library 
throws instead, the application can do its cleanup and then exit gracefully.

The assert in the smart_ptr case is a different, since asserting rather 
than dereferencing a null pointer is merely moving the inevitable 
SEGV/core dump up a bit to a place where it's probably a bit easier to 
debug.

So that's my opinion.  A general purpose, reusable library should throw 
unless it *knows* that to continue will result in an immediate crash.

-- 
Jon Biggar
Floorboard Software
jon_at_[hidden]
jon_at_[hidden]