View mode: basic / threaded / horizontal-split · Log in · Help
May 26, 2004
Re: Question about assertions
In article <c92nrh$2n9j$1@digitaldaemon.com>, Walter says...
>
>
>"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 ...");

In a former job, I was in the practice of writing such an assert like this:

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

I suppose the D equivalent is:

assert((err < 0) || (!"Could not negotiate hardware parameters".length));

It only 'computes' the second part if the assert fails, and you get a semi
readable message...  Of course it all disappears in release mode.

Kevin
May 26, 2004
Re: Question about assertions
In article <c92nrh$2n9j$1@digitaldaemon.com>, Walter says...
>
>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.

And new assert functions can always be written if special information is
desired.

Sean
May 26, 2004
Re: Question about assertions
On Wed, 26 May 2004 21:10:08 +0000, Sean Kelly wrote:

> And new assert functions can always be written if special information is
> desired.
> 
> Sean

This is not strictly true. If a user replaces the built-in assert with a
custom one, a custom one cannot report the line number of a failed assertion,
while the builtin one can.

Mike Swieton
__
The difference between losers and winners is that losers don't fail enough.
	- Ross Jeffries
May 26, 2004
Re: Question about assertions
In article <pan.2004.05.26.23.06.25.423500@swieton.net>, Mike Swieton says...
>
>On Wed, 26 May 2004 21:10:08 +0000, Sean Kelly wrote:
>
>> And new assert functions can always be written if special information is
>> desired.
>
>This is not strictly true. If a user replaces the built-in assert with a
>custom one, a custom one cannot report the line number of a failed assertion,
>while the builtin one can.

Oops!  I forgot about the lack of macros in D.  It would be nice to have assert
be extensible or at least to have module and line number information availble in
another way.  Can't say I use them myself, but I've seen versions of assert that
launch dialog windows and do debugger magic, and I'd have to lose line info in
the process.

Sean
May 27, 2004
Re: Question about assertions
Walter wrote:

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

But then you need to go to the code, add the printf, and try to repeat 
the same error. Then afterwoods removed the printf, or put in another 
test that occurs at debug time.  In many cases repeating the same error 
can be very difficult without knowledge of what the data was at that 
time.  I think it would be better to have the assert print out some of 
the data at that time.   A lot of effort to get one variable when the 
code could be written much easier into an assert.

ie compare:

debug
{
 if (!condition)
 {
      printf("", ...);
  }
}
assert(condition);

to

assert(condition, "", ...);



-- 
-Anderson: http://badmama.com.au/~anderson/
May 27, 2004
Re: Question about assertions
Walter wrote:

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

But your working on a compiler.  The conditions are easily re-produced 
in that type of program.

-- 
-Anderson: http://badmama.com.au/~anderson/
May 27, 2004
Re: Question about assertions
If Walter could somehow expose the line-number for the source, then one
could write their own assert. ... perhaps he can rig up a funky mixin?

- Kris


"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
news:c93lar$119p$1@digitaldaemon.com...
> Walter wrote:
>
> >My normal practice is to put some debugging printf's before the assert,
and
> >rerun the program.
> >
> >
>
> But then you need to go to the code, add the printf, and try to repeat
> the same error. Then afterwoods removed the printf, or put in another
> test that occurs at debug time.  In many cases repeating the same error
> can be very difficult without knowledge of what the data was at that
> time.  I think it would be better to have the assert print out some of
> the data at that time.   A lot of effort to get one variable when the
> code could be written much easier into an assert.
>
> ie compare:
>
> debug
> {
>   if (!condition)
>   {
>        printf("", ...);
>    }
> }
> assert(condition);
>
> to
>
> assert(condition, "", ...);
>
>
>
> --
> -Anderson: http://badmama.com.au/~anderson/
May 27, 2004
Re: Question about assertions
On Wed, 26 May 2004 20:09:05 -0700, Kris wrote:

> If Walter could somehow expose the line-number for the source, then one
> could write their own assert. ... perhaps he can rig up a funky mixin?
> 
> - Kris

I forget where, but there is a currLine/currFile variable somewhere that
you can access. The problem is, then your assert becomes something like:

void assert(bool, char[] msg, int line, char[] filename);

which, of course, can't be macro'd away. I'm not sure how I'd go about solving
this. Last time I thought about it, I suggested another magic variable for the
line of the call site, which is a terrible hack I can't really endorse.

Perhaps all that's needed is an overload for assert that could throw a
specific instance of an exception, or AssertError. The implementation would
need to be rather magic (to provide the right line numbers, etc.), but a whole
lot can be done when one has the ability to control the error class thrown.
Still ugly, though, and hard to extend, etc. I really dislike having
fundamental constructs that really aren't quite good enough (D's unit testing
is like this, as well. But I've already ranted about that).

I would be extremely interested to see a proposal for a genuinely good assert,
that would: allow line numbers/file names, messages, and hopefully arbitrary
class data to be passed along and reported.

Mike Swieton
__
What progress we are making. In the Middle Ages they would have burned me. Now
they are content with burning my books.
	- Sigmund Freud, in 1933
May 27, 2004
Re: Question about assertions
"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
news:c93ll4$120a$1@digitaldaemon.com...
> Walter wrote:
> >My normal practice is to put some debugging printf's before the assert,
and
> >rerun the program.
> But your working on a compiler.  The conditions are easily re-produced
> in that type of program.

Compilers aren't the only programs I've written. For GUI programs, I'd have
the printf's write to a log file. As for reproducing the error, that can be
tricky in, for example, multithreaded programs, but you cannot fix it and
verify the fix anyway until you can find a way to reproduce it.

Just printing out the value of the assert variable rarely is sufficient
anyway, as it is usually the tail end of a problem that started sometimes
much earlier.
May 27, 2004
Re: Question about assertions
Walter wrote:

>"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
>news:c93ll4$120a$1@digitaldaemon.com...
>  
>
>>Walter wrote:
>>    
>>
>>>My normal practice is to put some debugging printf's before the assert,
>>>      
>>>
>and
>  
>
>>>rerun the program.
>>>      
>>>
>>But your working on a compiler.  The conditions are easily re-produced
>>in that type of program.
>>    
>>
>
>Compilers aren't the only programs I've written. For GUI programs, I'd have
>the printf's write to a log file. As for reproducing the error, that can be
>tricky in, for example, multithreaded programs, but you cannot fix it and
>verify the fix anyway until you can find a way to reproduce it.
>
>Just printing out the value of the assert variable rarely is sufficient
>anyway, as it is usually the tail end of a problem that started sometimes
>much earlier.
>  
>
Right but being able to print values out in an assert would help.  
Normally when I've found a unique variable for the error I can work the 
code backwards and it is more easily reproducible.

-- 
-Anderson: http://badmama.com.au/~anderson/
1 2 3 4
Top | Discussion index | About this forum | D home