From: Russell Hind (rhind_at_[hidden])
Date: 2003-07-18 12:22:28
Daniel Frey wrote:
>
> Well, your use-scenario is of course reasonable and it makes perfectly
> sense to abort the process. But the point is that it's not up to the
> library to make that decision. I hope you can confirm that it was just
> the mix up of assert() and BOOST_ASSERT() that caused our disagreement.
> As I said, BOOST_ASSERT is perfectly fine for me...
>
No, I didn't mix up BOOST_ASSERT with assert I'm affraid. (haven't
looked at BOOST_ASSERT yet, so didn't realise you could change its
behaviour. But since you've mentioned it, I think boost assert should
be used. As I've said before, there are quite a few places assert() is
called, rather than BOOST_ASSERT in the boost src.
I prefer asserts now because our asserts used to throw and as I've said,
destructors that used to assert, started to throw which meant that
expected exceptions started to cause aborts and so it seemed a worse
situation that we were originally in. If we'd realised this at the
time, or were re-working the code completely we could take into account
that asserts through, but this was too much work.
I do see your point about library writers should give users the choice
of the so maybe this is the 'solution' for all.
The original post was really because I know I'm never going to put a
try...catch around locking a lock because it isn't an error I'm
expecting at runtime execept in the case of a coding error. And if you
disable asserts (in release code) then the try...catch becomes useless
as the method will never throw.
Thanks
Russell