www.digitalmars.com         C & C++   DMDScript  

D - Question about assertions

reply Mike Hearn <mike navi.cx> writes:
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
Apr 16 2004
next sibling parent J C Calvarese <jcc7 cox.net> writes:
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/
Apr 16 2004
prev sibling next sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
    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
Apr 17 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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/
Apr 17 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
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
Apr 17 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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/
Apr 17 2004
next sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
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
Apr 17 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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 26 2004
next sibling parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
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 26 2004
parent Mike Swieton <mike swieton.net> writes:
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 26 2004
prev sibling next sibling parent "Walter" <newshound digitalmars.com> writes:
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c93lar$119p$1 digitaldaemon.com...

 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.


Yes, that's life debugging programs. The skill comes in developing test
cases that trigger the fault, and in putting in just the right printf to pin
down where things go wrong.
May 26 2004
prev sibling next sibling parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
If it helps at all, there's now a Log4J clone underneath the Mango Tree at
dsource.org, and if one were to hook up a set of servlet-based forms (via
mango.servlet of course) for displaying and configuring the Log4J attributes
in one's running application ...

- 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 31 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
Agree

"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/
Jun 04 2004
prev sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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 26 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"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 26 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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/
May 26 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c93r3r$1a8c$1 digitaldaemon.com...

 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.


I'd like to put it another way. What's the reason not to supply a slightly more
informative assert? Even if we can just have a message string, a la the C/C++
message_assert idiom, that would be very helpful.
Jun 04 2004
prev sibling next sibling parent James Widman <james jwidman.com> writes:
In article <c93q92$18q9$1 digitaldaemon.com>,
 "Walter" <newshound digitalmars.com> 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.


For anyone who wasn't aware, there's an interesting article in the June 
2004 CUJ: "Debugging Real-Time Production Software".  

Basically it's about creating a special (low-priority) debugging thread 
that not only buffers and writes out log messages (sent to it from other 
threads) but also can be used to set, enable, and disable breakpoints 
while the program runs. 

When those breakpoints are enabled and reached, the process does not 
stop; instead, special breakpoint functions are called and execution 
continues, so the app behaves more like it would in the wild. 

That might help MT coders more than just string literals in asserts. 

And it probably won't involve any language changes to set that up in D  
-- though it would be pretty sweet if a development environment came 
with a debugging API and IDE integration so as to ease the use of a 
technique like that.
May 27 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:c93q92$18q9$1 digitaldaemon.com...

 "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.


Good point, but there are times when what's been asked for is useful.


 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.


Depends how much assertion you have. If (near-)full coverage is there, the first
trigger will be very close to the error source.
Jun 04 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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
next sibling parent Andy Friesen <andy ikagames.com> writes:
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
May 26 2004
prev sibling next sibling parent Kevin Bealer <Kevin_member pathlink.com> writes:
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
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
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
parent reply Mike Swieton <mike swieton.net> writes:
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
next sibling parent reply Sean Kelly <sean f4.ca> writes:
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 26 2004
parent Kevin Bealer <Kevin_member pathlink.com> writes:
In article <c939g8$h6d$1 digitaldaemon.com>, Sean Kelly says...

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


In a debugger, you can trace the stack back.  If there was an interface to do
this from inside the program, you would not need the "file, line, module, class"
pseudo variables of the c preprocessor.

For any function, current_function_name(uint i) and current_line_number(uint i)
would return the information, with i=0 being the current function and i = 1
being the calling function.  They would return empty data for the non-debug
case.

This would open doors to the development of a great deal of debugging-assistance
development, which for the first time would be portable.  It would only need to
be available in Debug mode, unless a special compiler option was used.

(In debug mode) this would insert code in the begin (end) of functions, which
would add (remove) the function name and line number to a stack.  Alternately,
the system could take advantage of existing debugging symbols stored in the
object code.

The release version of the (retrieval) functions would just return nothing,
likewise if the index (i) was too high (off the stack).

Kevin
May 27 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
D gets the language and compiler and user code to work together with
foreach/opApply. Why can we not have something similar for assert()?

"Mike Swieton" <mike swieton.net> wrote in message
news:pan.2004.05.26.23.06.25.423500 swieton.net...

 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
Jun 04 2004
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
I would agree that adding a string that describes the error is probably 
unnecessary.  But if you throw an exception, as I believe assert 
currently does, you lose valuable context info (stack backtrace and 
variables) that would be useful in debugging the problem.

I think that the current assert() is a good, basic default.  But I want 
to be able to write a program that does this:

function()
->assert(...)
   ->assertFailed(...)
     ->takeCoreDump()
     ->crash()

What is the best way to implement this?

Walter wrote:

 "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
parent reply "Walter" <newshound digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:c93v0g$1g48$1 digitaldaemon.com...

 I would agree that adding a string that describes the error is probably
 unnecessary.  But if you throw an exception, as I believe assert
 currently does, you lose valuable context info (stack backtrace and
 variables) that would be useful in debugging the problem.


But a decent debugger gives you that already. Why put it in the language?
May 27 2004
next sibling parent Kevin Bealer <Kevin_member pathlink.com> writes:
In article <c959fd$17un$2 digitaldaemon.com>, Walter says...

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:c93v0g$1g48$1 digitaldaemon.com...

 I would agree that adding a string that describes the error is probably
 unnecessary.  But if you throw an exception, as I believe assert
 currently does, you lose valuable context info (stack backtrace and
 variables) that would be useful in debugging the problem.


But a decent debugger gives you that already. Why put it in the language?


interface DebugModule {
void at_line(uint line, char[] function, char[] module);
void enter_function(uint line, char[] function, char[] module);
void exit_function(uint line,  char[] function, char[] module);
void modify_variable(uint var_line, char[] varname,
uint mod_line, char[] modname);
}

If I could write a handler matching an interface like the one above, and the
compiler knew how to put hooks in the language for it, I could create a debugger
that was written in D.  If I had access to a portable D GUI library it could run
on any platform.

Instead of zero or one good debuggers being available (ie does GDB count as
good?, opinion varies), I would have anything I can write.  Currently, I can't
write a portable debugger without a lot of knowledge about assembler and object
file format; consequently there is about one debugger per compiler.

I could write a module that does debugging via a GUI pop-up widget; it wouldn't
have all the down-on-the-metal knowledge that GDB has, but I could have it pop
into debug mode based on arbitrary decisions in the code.  There used to be a
way to do this, known as "dropping into a monitor" or similar, although monitors
were very primitive.

The code that I am suggesting to insert in functions at various points would be
something like:

if (global_debugger() !== null)
line_number_hook(__FUNCTION__, __LINE__, __MODULE__);

To attach a user created "diagnostics" module, there would be a similar call:

global_debugger(new GtkDebugModule);

or:

global_debugger(null); // return to non-calling-hooks mode.

Kevin
May 28 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:c959fd$17un$2 digitaldaemon.com...

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:c93v0g$1g48$1 digitaldaemon.com...

 I would agree that adding a string that describes the error is probably
 unnecessary.  But if you throw an exception, as I believe assert
 currently does, you lose valuable context info (stack backtrace and
 variables) that would be useful in debugging the problem.


 But a decent debugger gives you that already. Why put it in the language?


Flexibility. I've not yet used a debugger on D, and have reasonably high-level
in
the quality of the libraries through a combination of DbC and manually inserting
and then removing error strings. Message assertions would have simply meant that
I would have spent less time writing those same libs, time which I could have
spent on other libs or pontificating on this NG.
Jun 04 2004