May 26, 2004
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
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
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
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
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
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
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
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
"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
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/