Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-03-19 14:26:51

--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: <williamkempf_at_h...>
> > > Yes it does, but I'm not sure I like them. I generally follow
> > > the rule "assert the invariant".
> >
> > Others have said "assert the precondition".
> The important thing is not whether an invariant or a precondition
does not
> hold, but rather do you know who is to blame?
> If you know that the caller did something wrong, say "documented
> behavior" and do whatever you like.

This is the part that's still tricky to me, at least in this
particular case. The violations are user violations (almost all
precondition violations are user violations by definition). Here you
say to call it undefined behavior and to do what ever I like, but
earlier it was stated that all undefined behaviors should be
asserted, which makes sense at a high level. The problem is, asserts
terminate the app and are detectable only when "turned on". The
original thread that started this was the checks on misuse of locks
(which may in the future be extended to deadlock detection above and
beyond the normal checks). This condition can often arise from race
situations in threaded programming so checking only when the
assertions are turned on can result in undefined behavior that's
never caught during debugging. Further, it's a situation in which
many programs can easily and safely recover from the error. So both
qualities of the assert _seem_ detrimental to use here.

The thread_error added as error checking for the calls to the
underlying APIs would be much more appropriate for assertions,
however. This is something I'll change soon, regardless of the rest
of this.

Bill Kempf

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