On Wed, Jun 21, 2000 at 11:23:31AM +0900, Osamu Shigematsu wrote:
>
> I know, but if defined the NDEBUG macro, assert() do nothing, right? If we
> don't need a check, assert() should not be placed there. LAME is still under
> developing, but, assert() should not be good solution for error handing. It
> should be return error like exit().
Yes, aasert() is *not* for error handling, it is for catching errors in the
program code, i.e. coding errors. An example would be checking for NULL
pointers in pointer arguments for functions that, by design, do not handle
NULL pointers. If such a function gets passed a NULL pointer, then this
means an error in the caller's code, because the caller is expected to know
that a NULL pointer is not a valid argument for that function. Another
example is to check that numeric variables are in the expected ranges, or
that a data structure is in a consistent state.
This is part of the interface "contract" between a funtion and its caller;
the caller promises to provide valid arguments, and the function promises to
then perform some operation according to its specification. When the
respective programmers write correct code, then these promises are always
met. So assertions do check conditions that *should* always be true, but
since programmers make errors, it's a good idea to check them anyway, at
least during the debugging phase.
The main difference between failed assertions and errors is that the
occurrence of errors is something beyond the programmer's control (i.e. I/O
errors, out of memory, wrong or inconsistent information given by the user
of the program, etc.), whereas assertions are completely under the
programmer's control (i.e. if they fail, it's the programmer's fault).
One could decide to turn assertion failures (or at least some of them) into
runtime errors (e.g. "internal error" or something), and try to recover
somehow; but since there's usually no good way to recover (since the
assertion failure means a fundamental flaw in the program), and since
assertions can be potentially expensive in runtime and/or space, they are
usually not turned into errors, and checking is disabled in the "final"
code, even though on cannot be 100% sure that it doesn't contain any
programming errors any more (it almost always still does).
-- Niklas
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
