Boost logo

Boost :

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.



Boost list run by bdawes at, gregod at, cpdaniel at, john at