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

From: Russell Hind (rhind_at_[hidden])
Date: 2003-07-18 05:19:34

Daniel Frey wrote:
> 
> 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?
> 

Ok (and this could go on for ages), but shared_ptr asserts in operator-> 
if px is NULL.  Surely in that case, you would prefer shared_ptr to 
throw rather than assert.  It again is a logic error because the user 
hasn't assigned it a valid value.

You could replace all asserts with exceptions, so why hasn't this been 
done? :) .  But I see them as different error trapping methods.  I'm 
trying to decide when I should make code assert and when I should make 
code throw.  My basic presmise at the moment is that if it is a logic 
error, then assert.  If it is an error that can only be caught at 
runtime then it throws.

But there are easy exceptions to these rulse (1 I've come accross this 
morning).  I'm converting from a string to a value, but the the string 
is invalid so I could say the above code passed in a wrong value, so I 
can assert, but, IMHO, it is unfair to force the above code to check 
that value they are about to pass against all possible values because 
that is what the function is about to do.  So the function throws (I 
suppose it could have returned an error value rather than valid value, 
but thats a different matter).

So ultimately, it must come down to preferences.  I don't have a 
problem, and the functios to document how they work.  As you say, in a 
perfect world (of which I am not part :) ) then this would be fine, but 
it isn't.

But then some errors should have been caught in testing, and not allowed 
out in the field is valid in practice. We followed the same thought as 
you and made our assertions throw so the exception could be caught and 
the rest of the program continue.

But this caused more problems that it solved in the end because we now 
ended up with many methods that just used to assert, now throwing at 
run-time and many of these methods were called from destructors.  The 
mess that happened was that destructors ended up throwing which they 
should never do.  I don't have a problem with destructors asserting, but 
I do with them throwing, so I still like assertions and try to build up 
testing to catch assertions before they are put out to real use.

Thanks

Russell