Boost logo

Boost :

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-03-19 12:21:54


From: Peter Dimov <pdimov_at_[hidden]>
> From: "Greg Colvin" <gcolvin_at_[hidden]>
>
> > > 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."
> >
> > So the documentation is this? "If there is an error in my code,
> > or the compiler that compiled it, or the system code that it depends
> > on, or the hardware that the system code depends on, or any other
> > unforseen circumstance, then undefined behavior might occur. Use at
> > your own risk."
>
> No.
>
> When the code does not work like the documentation says it will work,
> including any documented "undefined behavior" cases, then it has a bug.
>
> I say that we should separate error reporting from bug reporting. It may not
> be appropriate to use the same mechanism for both.
>
> In other words:
>
> Error class #1: the programmer that wrote the application (that calls the
> library) has a bug in his/her code.
>
> Library Action: (documented) undefined behavior.
>
> Error class #2: a runtime error occurred in the library that the application
> programmer should handle.
>
> Library Action: (documented) throw an exception.
>
> Error class #3: the library, or the compiler, or the OS has a bug that can
> be detected. Depending on the situation, the bug may or may not prevent the
> library from functioning properly.
>
> Library Action: (undocumented) report the error via the appropriate
> mechanism.
>
> My point is that a plain assert is fine for #1, but may or may not be the
> best choice for #3.

Aha. We are in violent agreement then, and discussion comes down
to what is the appropriate mechanism? I still think plain assert
may be fine, especially if testing and review are supposed to have
caught whatever problems exist. A more configurable mechanism would
also be fine, but I would like to see any such mechanism boostified
too, rather than provided ad hoc for just the thread library.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk