• Francois Beausoleil (6/6) Jul 26 2004 How about a construct such as this:
• Sean Kelly (4/8) Jul 26 2004 Personally, I like having to go to the source code. Assertions taken ou...
• Arcane Jill (23/27) Jul 26 2004 One needs the source code to fix the bug anyway - however, there might b...
• Derek Parnell (11/17) Jul 26 2004 I think that asserts are meant to be read by the coder - the user of the

Francois Beausoleil <Francois_member pathlink.com> writes:

How about a construct such as this:
assert(lines == 3, "Expected to have found three lines");

Without the message, one needs the source code to find out what the failed
assertion means.

Thanks !
François

Sean Kelly <sean f4.ca> writes:

In article <ce3kob$1d6f$1 digitaldaemon.com>, Francois Beausoleil says...
How about a construct such as this:
assert(lines == 3, "Expected to have found three lines");

Without the message, one needs the source code to find out what the failed
assertion means.

Personally, I like having to go to the source code.  Assertions taken out of
context could mean nearly anything.

Sean

Arcane Jill <Arcane_member pathlink.com> writes:

In article <ce3kob$1d6f$1 digitaldaemon.com>, Francois Beausoleil says...
How about a construct such as this:
assert(lines == 3, "Expected to have found three lines");

Without the message, one needs the source code to find out what the failed
assertion means.

One needs the source code to fix the bug anyway - however, there might be
circumstances where it becomes useful. Suppose a third party implements this
function in a library:











Now, if you call this function with f(1000), you're going to get an assert - but
in this case the bug is in /your/ code (because you have violated the function's
in-contract). And yet, because this is a third-party library, it is possible
that you might not have access to its source code. How, then, are you to know
what f's contract is?

I think it was Ben who said that in-contracts are (should be) part of a
function's interface. I don't know if it's possible to specify just the
in-contract in a stripped down header file, but if it is, that's the way to go -
in which case, you /still/ don't need an extra text message.

Arcane Jill

Derek Parnell <derek psych.ward> writes:

On Mon, 26 Jul 2004 19:06:51 +0000 (UTC), Francois Beausoleil wrote:

 How about a construct such as this:
 assert(lines == 3, "Expected to have found three lines");
 
 Without the message, one needs the source code to find out what the failed
 assertion means.
 

I think that asserts are meant to be read by the coder - the user of the
source code. This doesn't mean that the coder wouldn't appreciate the
_hint_ text, but they should also have access to the source. 

It would be unusual to have assert messages coming out from a library that
has been distributed by somebody else, except if they also distributed a
special _debug_ version of the library.

-- 
Derek
Melbourne, Australia
27/Jul/04 10:05:36 AM