Hi,

Why does assert() not allow you to add a textual string identifying the
problem?

Otherwise you get the problem alsalib has, where you get useless messages like:

snd_pcm.c: assertion "err < 0" failed

which tells you nothing about what the assert *actually tested* in the semantic sense, rather than the expression sense.

Is there a reason we can't have an extension that lets you write?

   assert( err < 0, "Could not negotiate hardware parameters" );

or something to that effect?

thanks -mike

Mike Hearn wrote:
> Hi,
> 
> Why does assert() not allow you to add a textual string identifying the
> problem?
> 
> Otherwise you get the problem alsalib has, where you get useless messages
> like:
> 
> snd_pcm.c: assertion "err < 0" failed
> 
> which tells you nothing about what the assert *actually tested* in the
> semantic sense, rather than the expression sense.
> 
> Is there a reason we can't have an extension that lets you write?
> 
>    assert( err < 0, "Could not negotiate hardware parameters" );
> 
> or something to that effect?
> 
> thanks -mike

I agree that we need this. Similar ideas have been made mentioned before. My suggestion is to add an optional printf-like output string to the existing assert statement.

Syntax:   assert(testExpression, formattingString, ...);

Example:  assert(x==1, "x is wrong.\nx: %d", x);

Output:   x is wrong.
          x: 1

(http://www.digitalmars.com/drn-bin/wwwnews?D/25591)


-- 
Justin
http://jcc_7.tripod.com/d/

>    assert( err < 0, "Could not negotiate hardware parameters" );

assert( (err < 0) && "Could not negotiate hardware parameters" );

BTW, you don't want such thing to be an assert - asserts are for programmer's error only and are not included in release builds. Use your own construct for run-time errors. Currently, unlike C assert, D assert does not output offensive code either - only file and line, so you could just as well write in a comment.

Changing the current established implementation would shift assert use also to make run-time diagnostic in some code, some code would still follow the D standard, and then we have real chaos! One would not be able to use relase mode any longer, since it would exclude important checks for run time conditions.

-eye

Ilya Minkov wrote:

> >    assert( err < 0, "Could not negotiate hardware parameters" );
>
> Changing the current established implementation would shift assert use also to make run-time diagnostic in some code, some code would still follow the D standard, and then we have real chaos! One would not be able to use relase mode any longer, since it would exclude important checks for run time conditions.
>
> -eye

I don't believe this at all.  Give programmers some credit.  assert would have already gone this way in C++, if what you say is true.  One reason for adding these diagnostic checks is for code maintainers, who would be able to compile their own debug versions of the code.

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson schrieb:

> I don't believe this at all.  Give programmers some credit.  assert would have already gone this way in C++, if what you say is true.  One reason for adding these diagnostic checks is for code maintainers, who would be able to compile their own debug versions of the code.

Oh yeah? See that example by Mike which shows the most invalid use of assert - and it's from ALSA! It actually is unavoidable that one project  or another does it this silly way. I was undecided for a long time - that is i tended to the view that more verbose asserts with user text are better, but i have changed my mind and i support Walter now because i see the reason.

-eye

Ilya Minkov wrote:

> J Anderson schrieb:
>
>> I don't believe this at all.  Give programmers some credit.  assert would have already gone this way in C++, if what you say is true.  One reason for adding these diagnostic checks is for code maintainers, who would be able to compile their own debug versions of the code.
>
>
> Oh yeah? See that example by Mike which shows the most invalid use of assert - and it's from ALSA! It actually is unavoidable that one project  or another does it this silly way. I was undecided for a long time - that is i tended to the view that more verbose asserts with user text are better, but i have changed my mind and i support Walter now because i see the reason.
>
> -eye

I don't know about you but when the program breaks I want to know about all the ralevent variables and what they were up too.  In many cases it is difficult to repeat the same bug, unless you have this information.  If you can't work out why it crashed there, what do you go and do?  Run the code through a debugger and put a conditional breakpoint at that assert (trying to repeat the same bug), just to get the state of the variables.

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson schrieb:

> I don't know about you but when the program breaks I want to know about all the ralevent variables and what they were up too.  In many cases it is difficult to repeat the same bug, unless you have this information.  If you can't work out why it crashed there, what do you go and do?  Run the code through a debugger and put a conditional breakpoint at that assert (trying to repeat the same bug), just to get the state of the variables.

Ok, you are also right, sorry.

-eye

"Mike Hearn" <mike@navi.cx> wrote in message news:pan.2004.04.16.22.38.14.275716@navi.cx...
> Hi,
>
> Why does assert() not allow you to add a textual string identifying the
> problem?
>
> Otherwise you get the problem alsalib has, where you get useless messages like:
>
> snd_pcm.c: assertion "err < 0" failed
>
> which tells you nothing about what the assert *actually tested* in the semantic sense, rather than the expression sense.
>
> Is there a reason we can't have an extension that lets you write?
>
>    assert( err < 0, "Could not negotiate hardware parameters" );
>
> or something to that effect?

Asserts are only for debugging purposes by the programmer who wrote the code, and the first thing the programmer will do is bring up the corresponding file/line in the editor. Presumably there will be some comment there explaining it. I don't see how adding a redundant string in the assert message itself adds value to this.

If you're writing code that will be seen by the user, instead use something like:

    if (!expression) throw new Exception("we failed because ...");

"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:c5s3qp$27v0$1@digitaldaemon.com...
> I don't know about you but when the program breaks I want to know about all the ralevent variables and what they were up too.  In many cases it is difficult to repeat the same bug, unless you have this information. If you can't work out why it crashed there, what do you go and do?  Run the code through a debugger and put a conditional breakpoint at that assert (trying to repeat the same bug), just to get the state of the variables.

My normal practice is to put some debugging printf's before the assert, and rerun the program.

Walter wrote:
> Asserts are only for debugging purposes by the programmer who wrote the
> code, and the first thing the programmer will do is bring up the
> corresponding file/line in the editor. Presumably there will be some comment
> there explaining it. I don't see how adding a redundant string in the assert
> message itself adds value to this.
> 
> If you're writing code that will be seen by the user, instead use something
> like:
> 
>     if (!expression) throw new Exception("we failed because ...");

What about implementing a closed-source library?  Would it be bad style to use contracts to assert that the library is used properly?

Or is it possible to prototype the body of a method but provide contracts?  ie

class MyClass : ... {
   void foo()
   in { ... }
   out { ... }
   body;
}

 -- andy