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 (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,


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,


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,


rerun the program.

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,
      


rerun the program.
      

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.

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,


rerun the program.

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.

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,


rerun the program.

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,


rerun the program.

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