View mode: basic / threaded / horizontal-split · Log in · Help
April 16, 2004
Question about assertions
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
April 16, 2004
Re: Question about assertions
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/
April 17, 2004
Re: Question about assertions
>    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
April 17, 2004
Re: Question about assertions
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/
April 17, 2004
Re: Question about assertions
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
April 17, 2004
Re: Question about assertions
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/
April 17, 2004
Re: Question about assertions
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
May 26, 2004
Re: Question about assertions
"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 ...");
May 26, 2004
Re: Question about assertions
"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.
May 26, 2004
Re: Question about assertions
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
« First   ‹ Prev
1 2 3 4
Top | Discussion index | About this forum | D home