Re: level argument for assert

[Philipp Janda <siffiejoe@...>]

Am 03.01.2013 15:15, schrieb Dirk Laurie:
> > I think what you're looking for is not called assert().
>
> Amen. The suggested usage does not fit the purpose.

Maybe assert's purpose in C and in Lua is different from each other. 
They certainly have different characteristics:

C:
- automatically generated, cryptic (for end users) error message
- forces a crash, no resource cleanup
- core dump
- vanishes if NDEBUG is defined

Lua:
- optional custom error message
- raises a normal error which can be handled by standard means
- doesn't magically disappear depending on compilation flags

C's assert is clearly intended to report programming bugs to 
programmers, while Lua's assert is inferior compared to `error()` for 
reporting errors to end users in only one way: It doesn't support a 
level argument. And this is what this thread is all about ...

Of course one could argue that `error()` isn't supposed to be used for 
error reporting to end users as well.

IMHO, assert's primary purpose in Lua is to convert return values to 
errors. I also find it more readable than "if ... then error( ... ) end" 
for simple conditions like argument checks.

So why doesn't/shouldn't assert support a level parameter if error does? 
Because it is easy for error and difficult for assert.

> [...]
>
> The way I was taught to use  "assert"  is exemplified int he C
> code for the GMP package.  You don't use it directly but via
> a macro.
>
>      ASSERT(x>=0,"x should not be negative");

Why? C's assert already is a macro and works (almost) the same way:

    assert( x>=0 && "x should not be negative" )

> You define the macro to call the C "assert" macro while debugging
> the program.  There are well over 3000 instances of ASSERT in
> the code.  Once the program works, you don't take out all the
> asserts but redefine the macro to  generate no code at all.  GMP
> automates all that by a preprocessor variable WANT_ASSERT.

It's NDEBUG for assert.

> [...]
>
> In production, users will sooner or later uncover a mistake.
> That's when you restore the original assert, debug it, and
> deactivate it again.

Sometimes it's not easy to modify the user's code, so some C people 
leave the asserts in place even for production code.

Philipp