Re: [boost] Re: Boost.Threads draft library submission

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-03-19 11:30:04

From: "Greg Colvin" <gcolvin_at_[hidden]>

> Except that, as I recall it, William's thread code is designed
> such that CloseHandle cannot fail.  If it does fail it is a bug,
> but not in the clients code.  And furthermore, the whole point
> of the thread code is for the client not to have to know or care
> about handles at all.  It is an artifact of the implementation
> on a particular system that there is a handle at all, that it
> needs closing, that it gets closed when it does, and that the
> call to close can fail.

Correct. So when the assert fires, this indicates a library bug or that
something unanticipated by the library designer happened.

What does the user gain? Library bugs should be caught by unit tests, not by
users-turned-beta-testers, at least in a perfect world.

It may be a good idea to output a warning using some kind of logging
mechanism, but the code should not "fail", whatever your definition of
"fail" is. Give the user the option to ignore the error - it's not his/her
fault. Cope with the error in the best way possible.

> So I have no trouble with an assert in this case, as it seems
> wrong to throw an exception that means "Something that was
> supposed to be impossible has happened, so all bets are off.
> Proceed at your own risk."

I agree that an exception is not appropriate. I'm arguing that (1)
undocumented "assert" uses are bad, and (2) the proper way to document an
"assert" is by using the term "undefined behavior."

> > Don't underestimate the rule "assert() only when the docs say 'undefined
> > behavior'". It only _looks_ like it's a no-brainer, but has deep
> > implications.
>
> Yes it does, but I'm not sure I like them.  I generally follow
> the rule "assert the invariant".

See above - the user gets an "Assertion failed - invariant()" message. So
what?

Of course, if the invariant is "p != 0", where p is a pointer, and the
method uses *p, there's nothing wrong with assert'ing that p != 0. We're in
undefined behavior land anyway, assert or not.

--
Peter Dimov
Multi Media Ltd.