www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - condition stringising in assert

reply "Matthew Wilson" <dmd synesis.com.au> writes:
Can I register yet another request for this long-looked-for feature?

I'm finding it rather painful that the output just prints "Error:
AssertError Failure vector(390)". It's just a PITA.

Can we get this for 1.0?
Jul 13 2004
next sibling parent Arcane Jill <Arcane_member pathlink.com> writes:
In article <cd077b$282s$1 digitaldaemon.com>, Matthew Wilson says...
Can I register yet another request for this long-looked-for feature?

I'm finding it rather painful that the output just prints "Error:
AssertError Failure vector(390)". It's just a PITA.

Can we get this for 1.0?
You could always do what I do these days, which is to replace: with or similar. Actually, I've never been entirely comfortable with assert()s, since they magically disappear in a release build. This is a good thing only if you're sure those asserts are never going to happen. Jill
Jul 13 2004
prev sibling next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew Wilson wrote:

Can I register yet another request for this long-looked-for feature?

I'm finding it rather painful that the output just prints "Error:
AssertError Failure vector(390)". It's just a PITA.

Can we get this for 1.0?


  
Yes, please. Speaking of asserts, another useful feature would be a continue (ie ignore/ignore all) option. That is particularly useful when working in a large group of people and someone stuffs up part of the build that is not very important to you (ie you working on graphics and someone stuff up the sound engine). Although I'm not exactly sure how that would work though. I think the best option (parhaps 2.0) is to allow for our own customisable asserts. That way we can stop things like timers, things over networks and graphics cards and re-start them again when continued. We can then also put up a nice OS based interface to deal with asserts. That is the safest option. -- -Anderson: http://badmama.com.au/~anderson/
Jul 13 2004
next sibling parent reply teqDruid <me teqdruid.com> writes:
void myAssert(bit condition, char[] message)
{
	if (condition)
		throw new myException(message);
}

I'm not sure what it is you're looking for that can't be done with
Exceptions.

On Tue, 13 Jul 2004 23:34:37 +0800, J Anderson wrote:

 Matthew Wilson wrote:
 
Can I register yet another request for this long-looked-for feature?

I'm finding it rather painful that the output just prints "Error:
AssertError Failure vector(390)". It's just a PITA.

Can we get this for 1.0?



  
Yes, please. Speaking of asserts, another useful feature would be a continue (ie ignore/ignore all) option. That is particularly useful when working in a large group of people and someone stuffs up part of the build that is not very important to you (ie you working on graphics and someone stuff up the sound engine). Although I'm not exactly sure how that would work though. I think the best option (parhaps 2.0) is to allow for our own customisable asserts. That way we can stop things like timers, things over networks and graphics cards and re-start them again when continued. We can then also put up a nice OS based interface to deal with asserts. That is the safest option.
Jul 13 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
teqDruid wrote:

void myAssert(bit condition, char[] message)
{
	if (condition)
		throw new myException(message);
}

I'm not sure what it is you're looking for that can't be done with
Exceptions.

  
The thing is the line-number+filename. Now you can do a stack trace but that's not very convenient in many situations, particularly if your working on a different OS which has no general console. Also message assert need to be standardised. Its an extreamly useful tool. Each developer (and they will) should not need to write their own. -- -Anderson: http://badmama.com.au/~anderson/
Jul 14 2004
parent teqDruid <me teqdruid.com> writes:
On Wed, 14 Jul 2004 22:46:12 +0800, J Anderson wrote:

 teqDruid wrote:
 
void myAssert(bit condition, char[] message) {
	if (condition)
		throw new myException(message);
}
}
I'm not sure what it is you're looking for that can't be done with
Exceptions.


  
The thing is the line-number+filename. Now you can do a stack trace but that's not very convenient in many situations, particularly if your working on a different OS which has no general console.
Asserts are useful, but I believe it would make the language more powerful if the line numbers and filenames were exposed to it, so Exceptions had access to that info.
 
 Also message assert need to be standardised.  Its an extreamly useful
 tool.  Each developer (and they will) should not need to write their own.
Jul 14 2004
prev sibling parent "Matthew Wilson" <dmd synesis.com.au> writes:
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:cd0odg$4rp$1 digitaldaemon.com...
 Matthew Wilson wrote:

Can I register yet another request for this long-looked-for feature?

I'm finding it rather painful that the output just prints "Error:
AssertError Failure vector(390)". It's just a PITA.

Can we get this for 1.0?
Yes, please. Speaking of asserts, another useful feature would be a continue (ie ignore/ignore all) option. That is particularly useful when working in a large group of people and someone stuffs up part of the build that is not very important to you (ie you working on graphics and someone stuff up the sound engine). Although I'm not exactly sure how that would work though.
Agreed. I was thinking along the same lines.
 I think the best option (parhaps 2.0) is to allow for our own
 customisable asserts. That way we can stop things like timers, things
 over networks and graphics cards and re-start them again when
 continued.  We can then also put up a nice OS based interface to deal
 with asserts.  That is the safest option.
Sounds useful
Jul 14 2004
prev sibling next sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Tue, 13 Jul 2004 18:39:05 +1000, Matthew Wilson <dmd synesis.com.au> 
wrote:
 Can I register yet another request for this long-looked-for feature?

 I'm finding it rather painful that the output just prints "Error:
 AssertError Failure vector(390)". It's just a PITA.

 Can we get this for 1.0?
I can't see the point myself. asserts only occur in debug builds, so end users never see them, so it's only you the developer that sees them, in which case you simply open the source and you can see what asserted. That said, when you do something like.. foreach(char[] s; testStrings) { ..etc.. assert(); } the file/line number for the assert does not tell you which testString failed. In which case I have used: foreach(char[] s; testStrings) { ..etc.. if () { printf(""); assert(); } } While on this topic, what does an assert do in a windows full screen 3d app? currently, I assume, it is printing to stderr and terminating the app. Can we over-ride that behaviour? I imagine a full screen 3d app does not have a console or a stderr, plus you want the assert box to popup in front of the full screen display. I have seen commercial games where the error box was hidden by the games main window with no way to see it. I think a global onAssert() method/function that if exists is called on assert would be very useful. Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 13 2004
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsa3k2sce5a2sq9 digitalmars.com...
 On Tue, 13 Jul 2004 18:39:05 +1000, Matthew Wilson <dmd synesis.com.au>
 wrote:
 Can I register yet another request for this long-looked-for feature?

 I'm finding it rather painful that the output just prints "Error:
 AssertError Failure vector(390)". It's just a PITA.

 Can we get this for 1.0?
I can't see the point myself. asserts only occur in debug builds, so end users never see them, so it's only you the developer that sees them, in which case you simply open the source and you can see what asserted.
Nonsense. What about users of libraries, i.e. developers? Look through the STLSoft source - in fact grep for "message_assert" - and you'll see just how useful a meaningful message in an assertion can be.
Jul 13 2004
next sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Wed, 14 Jul 2004 10:07:39 +1000, Matthew 
<admin stlsoft.dot.dot.dot.dot.org> wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsa3k2sce5a2sq9 digitalmars.com...
 On Tue, 13 Jul 2004 18:39:05 +1000, Matthew Wilson <dmd synesis.com.au>
 wrote:
 Can I register yet another request for this long-looked-for feature?

 I'm finding it rather painful that the output just prints "Error:
 AssertError Failure vector(390)". It's just a PITA.

 Can we get this for 1.0?
I can't see the point myself. asserts only occur in debug builds, so end users never see them, so it's only you the developer that sees them, in which case you simply open the source and you can see what asserted.
Nonsense. What about users of libraries, i.e. developers?
Open source or closed? If it's open source you can open the source and look.
 Look through the STLSoft source - in fact grep for "message_assert" - 
 and you'll
 see just how useful a meaningful message in an assertion can be.
The fact that I can, tells me this is open source, in which case if I got an assert I could open the source and look. Regardless, can you give me an example of when your library would assert. Is it because I called a function with incorrect parameters? or..? Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 13 2004
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsa3p7mzu5a2sq9 digitalmars.com...
 On Wed, 14 Jul 2004 10:07:39 +1000, Matthew
 <admin stlsoft.dot.dot.dot.dot.org> wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsa3k2sce5a2sq9 digitalmars.com...
 On Tue, 13 Jul 2004 18:39:05 +1000, Matthew Wilson <dmd synesis.com.au>
 wrote:
 Can I register yet another request for this long-looked-for feature?

 I'm finding it rather painful that the output just prints "Error:
 AssertError Failure vector(390)". It's just a PITA.

 Can we get this for 1.0?
I can't see the point myself. asserts only occur in debug builds, so end users never see them, so it's only you the developer that sees them, in which case you simply open the source and you can see what asserted.
Nonsense. What about users of libraries, i.e. developers?
Open source or closed? If it's open source you can open the source and look.
Yes, but sometimes the assert condition can be complex. If there's a simple message telling the user immediately what the problem is, then they've saved time. I can't see why that's not an attractive thing? It helps in many circumstances, but costs nothing and does no harm.
Jul 13 2004
next sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
Matthew wrote:

 
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsa3p7mzu5a2sq9 digitalmars.com...
 On Wed, 14 Jul 2004 10:07:39 +1000, Matthew
 <admin stlsoft.dot.dot.dot.dot.org> wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsa3k2sce5a2sq9 digitalmars.com...
 On Tue, 13 Jul 2004 18:39:05 +1000, Matthew Wilson
 <dmd synesis.com.au> wrote:
 Can I register yet another request for this long-looked-for feature?

 I'm finding it rather painful that the output just prints "Error:
 AssertError Failure vector(390)". It's just a PITA.

 Can we get this for 1.0?
I can't see the point myself. asserts only occur in debug builds, so end users never see them, so it's only you the developer that sees them, in which case you simply open the source and you can see what asserted.
Nonsense. What about users of libraries, i.e. developers?
Open source or closed? If it's open source you can open the source and look.
Yes, but sometimes the assert condition can be complex. If there's a simple message telling the user immediately what the problem is, then they've saved time. I can't see why that's not an attractive thing? It helps in many circumstances, but costs nothing and does no harm.
Here are a few message_assert's I've found in src/phobos/etc/c/stlsoft: winstl_message_assert("Attempting to increment an invalid iterator!", NULL != m_handle); winstl_message_assert("Dereferencing end()-valued iterator", 0); unixstl_message_assert("Shared search handle being destroyed with outstanding references!", 0 == cRefs); and it looks generally like these asserts are for cases when the user has incorrectly used the library. I agree for these types of asserts (if they should be asserts) a message helps the user correct their code. But a typical assert Walter uses is something like Internal Error: ..\ztc\cgcod.c 614 which means Walter (not the user) messed up and all he needs are some reproduction steps and the file and line number. Personally I tend to use asserts like you do and consider invalid usage to be assertable where Walter keeps asserts to only internal usage (I think Arcane Jill had also posted that's how she uses asserts). So I think it makes sense to have two different assert mechanisms for these two different usage models. Maybe there should be some sort of "private assert" and "public assert" and the public one has message strings and the private one doesn't. -Ben
Jul 13 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Tue, 13 Jul 2004 22:10:02 -0400, Ben Hinkle <bhinkle4 juno.com> wrote:
 Matthew wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsa3p7mzu5a2sq9 digitalmars.com...
 On Wed, 14 Jul 2004 10:07:39 +1000, Matthew
 <admin stlsoft.dot.dot.dot.dot.org> wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsa3k2sce5a2sq9 digitalmars.com...
 On Tue, 13 Jul 2004 18:39:05 +1000, Matthew Wilson
 <dmd synesis.com.au> wrote:
 Can I register yet another request for this long-looked-for 
feature?
 I'm finding it rather painful that the output just prints "Error:
 AssertError Failure vector(390)". It's just a PITA.

 Can we get this for 1.0?
I can't see the point myself. asserts only occur in debug builds, so end users never see them, so it's only you the developer that sees them, in which case you simply open the source and you can see what asserted.
Nonsense. What about users of libraries, i.e. developers?
Open source or closed? If it's open source you can open the source and look.
Yes, but sometimes the assert condition can be complex. If there's a simple message telling the user immediately what the problem is, then they've saved time. I can't see why that's not an attractive thing? It helps in many circumstances, but costs nothing and does no harm.
Here are a few message_assert's I've found in src/phobos/etc/c/stlsoft: winstl_message_assert("Attempting to increment an invalid iterator!", NULL != m_handle); winstl_message_assert("Dereferencing end()-valued iterator", 0); unixstl_message_assert("Shared search handle being destroyed with outstanding references!", 0 == cRefs); and it looks generally like these asserts are for cases when the user has incorrectly used the library. I agree for these types of asserts (if they should be asserts) a message helps the user correct their code. But a typical assert Walter uses is something like Internal Error: ..\ztc\cgcod.c 614 which means Walter (not the user) messed up and all he needs are some reproduction steps and the file and line number. Personally I tend to use asserts like you do and consider invalid usage to be assertable where Walter keeps asserts to only internal usage (I think Arcane Jill had also posted that's how she uses asserts). So I think it makes sense to have two different assert mechanisms for these two different usage models. Maybe there should be some sort of "private assert" and "public assert" and the public one has message strings and the private one doesn't.
Maybe... I think the crux of it is "what is assert worthy and what is an exception?" A commonly used assert, is one used when a parameter to your API is incorrect. Typically when using Windows C API calls there is an error code returned which says invalid parameter. As we don't use those in D, do we throw an exception OR use an assert in this case? I think in this case an exception allows the user of your API more flexibility. It may not be a fatal error for this particular API call to fail, they may want to catch and handle the exception. Using the above examples, an exception may be valid here...
  winstl_message_assert("Attempting to increment an invalid iterator!", 
 NULL
 != m_handle);
not sure, not really enough context. In other examples an assert may be perfectly valid, like here...
  unixstl_message_assert("Shared search handle being destroyed with
 outstanding references!", 0 == cRefs);
this seems to me to be one too many calls to a free function, probably due to a buggy algorithm/loop they used to call it. Basically what I'm saying is perhaps sometimes we use asserts and should have used an exception and vice-versa. I did voice an idea for an overload function onAssert() so as to modify the behaviour of how it outputs the assert. I don't think that is required any mode, I think if it's an error the end user needs to see it should be an exception. Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 13 2004
parent Arcane Jill <Arcane_member pathlink.com> writes:
In article <opsa32o5pf5a2sq9 digitalmars.com>, Regan Heath says...
A commonly used assert, is one used when a parameter to your API is 
incorrect. Typically when using Windows C API calls there is an error code 
returned which says invalid parameter. As we don't use those in D, do we 
throw an exception OR use an assert in this case?
We throw an exception, obviously. Otherwise you will never be able to test what happens when the user provides invalid input. Why not? Because in a debug build, the asserts will prevent invalid input from reaching the function, so the horror of that ACTUALLY HAPPENING (with consomate access violations, buffer overflows, whatever) will simply not occur ... in a debug build. So you'll never test it, and never write code to deal with bad user input. But invalid user input will make it through those asserts in a release build. And then guess what's gonna happen after that? Ouch! D is not C. A D assert is not the same thing as C assert. Arcane Jill
Jul 14 2004
prev sibling parent Regan Heath <regan netwin.co.nz> writes:
On Wed, 14 Jul 2004 11:12:44 +1000, Matthew 
<admin stlsoft.dot.dot.dot.dot.org> wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsa3p7mzu5a2sq9 digitalmars.com...
 On Wed, 14 Jul 2004 10:07:39 +1000, Matthew
 <admin stlsoft.dot.dot.dot.dot.org> wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsa3k2sce5a2sq9 digitalmars.com...
 On Tue, 13 Jul 2004 18:39:05 +1000, Matthew Wilson 
<dmd synesis.com.au>
 wrote:
 Can I register yet another request for this long-looked-for 
feature?
 I'm finding it rather painful that the output just prints "Error:
 AssertError Failure vector(390)". It's just a PITA.

 Can we get this for 1.0?
I can't see the point myself. asserts only occur in debug builds, so end users never see them, so
it's
 only you the developer that sees them, in which case you simply open 
the
 source and you can see what asserted.
Nonsense. What about users of libraries, i.e. developers?
Open source or closed? If it's open source you can open the source and look.
Yes, but sometimes the assert condition can be complex. If there's a simple message telling the user immediately what the problem is, then they've saved time. I can't see why that's not an attractive thing? It helps in many circumstances, but costs nothing and does no harm.
The cost is Walters time, the other features/things he does not do while he is doing this. Is this really something you *must* have for 1.0? or is it simply decoration. I think it's decoration as you can already get a 'nice' message by printing then asserting. Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 13 2004
prev sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cd1tgu$26qd$2 digitaldaemon.com>, Matthew says...

 asserts only occur in debug builds, so end users never see them, so it's
 only you the developer that sees them, in which case you simply open the
 source and you can see what asserted.
Nonsense. What about users of libraries, i.e. developers?
Not sure I agree with this. My Deimos library stuff does have asserts, but only because I expect them never to happen. They don't indicate that the library USER has done anything wrong, merely that I have a bug to fix. Fortunately, I am here, and people who discover such bugs can tell me about it. If I were not contactable, it still wouldn't matter too much because Deimos is open source, and so, theoretically, someone ELSE could fix it. But in the circumstance where (a) the library author were not contactable, and (b) the project were not open source, an assert would be a very bad thing to encounter. A throw of an exception (with a suitable error message) would be much more appropriate, methinks. Arcane Jill
Jul 14 2004
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:cd2o1k$mru$1 digitaldaemon.com...
 In article <cd1tgu$26qd$2 digitaldaemon.com>, Matthew says...

 asserts only occur in debug builds, so end users never see them, so it's
 only you the developer that sees them, in which case you simply open the
 source and you can see what asserted.
Nonsense. What about users of libraries, i.e. developers?
Not sure I agree with this. My Deimos library stuff does have asserts, but only because I expect them never to happen. They don't indicate that the library
USER
 has done anything wrong, merely that I have a bug to fix.

 Fortunately, I am here, and people who discover such bugs can tell me about it.
 If I were not contactable, it still wouldn't matter too much because Deimos is
 open source, and so, theoretically, someone ELSE could fix it.

 But in the circumstance where (a) the library author were not contactable, and
 (b) the project were not open source, an assert would be a very bad thing to
 encounter. A throw of an exception (with a suitable error message) would be
much
 more appropriate, methinks.
I don't agree. Exceptions are for exceptional conditions, i.e failures, not human errors. If you want to be "strict", then the right thing to do when a DbC condition is violated is to halt. An exception is not the appropriate response.
Jul 14 2004
next sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cd2rij$tra$1 digitaldaemon.com...
 "Arcane Jill" <Arcane_member pathlink.com> wrote in message
 news:cd2o1k$mru$1 digitaldaemon.com...
 In article <cd1tgu$26qd$2 digitaldaemon.com>, Matthew says...

 asserts only occur in debug builds, so end users never see them, so it's
 only you the developer that sees them, in which case you simply open the
 source and you can see what asserted.
Nonsense. What about users of libraries, i.e. developers?
Not sure I agree with this. My Deimos library stuff does have asserts, but
only
 because I expect them never to happen. They don't indicate that the library
USER
 has done anything wrong, merely that I have a bug to fix.

 Fortunately, I am here, and people who discover such bugs can tell me about
it.
 If I were not contactable, it still wouldn't matter too much because Deimos
is
 open source, and so, theoretically, someone ELSE could fix it.

 But in the circumstance where (a) the library author were not contactable,
and
 (b) the project were not open source, an assert would be a very bad thing to
 encounter. A throw of an exception (with a suitable error message) would be
much
 more appropriate, methinks.
I don't agree. Exceptions are for exceptional conditions, i.e failures, not
human
 errors. If you want to be "strict", then the right thing to do when a DbC
 condition is violated is to halt. An exception is not the appropriate response.
As the man himself says, if you don't want your process to halt when it's actually in an unsound state, what do you want it to do? One more thing: it seems to me that everyone always assumes that assertions are a debug-time feature only. There's absolutely no reason why this should be so, and I've worked on systems where they were always active (albeit they had different actions in debug and release mode).
Jul 14 2004
prev sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cd2rij$tra$1 digitaldaemon.com>, Matthew says...

I don't agree. Exceptions are for exceptional conditions, i.e failures, not
human
errors. If you want to be "strict", then the right thing to do when a DbC
condition is violated is to halt. An exception is not the appropriate response.
Eh?
Jul 14 2004
next sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:cd33r9$1cjn$1 digitaldaemon.com...
 In article <cd2rij$tra$1 digitaldaemon.com>, Matthew says...

I don't agree. Exceptions are for exceptional conditions, i.e failures, not
human
errors. If you want to be "strict", then the right thing to do when a DbC
condition is violated is to halt. An exception is not the appropriate
response.
 Eh?
Errors: A human failure to have coded something correctly. Fault: A condition that may legitimately result in the lifetime of a process within the context of its execution environment. Passing a null-pointer is an error. Failure to write to a file through lack of disk space is an exception. In almost all cases, a process should handle an exception, and take remedial action. Of course, one such action is to terminate the process - e.g. when out of memory - but that's rarely the best answer. The point made by Bertrand Meyer is that errors, which reflect coding failures, *not* environmental conditions, should result in termination of the process. Although this seems somewhat extreme, he sagely posits the question "what would you have an erroneous process do?". Is that any clearer?
Jul 14 2004
prev sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cd33r9$1cjn$1 digitaldaemon.com>, Arcane Jill says...
In article <cd2rij$tra$1 digitaldaemon.com>, Matthew says...

I don't agree. Exceptions are for exceptional conditions, i.e failures, not
human
errors. If you want to be "strict", then the right thing to do when a DbC
condition is violated is to halt. An exception is not the appropriate response.
Eh?
So what's wrong with this then? An assert is DEFINITELY not the right thing here. The input could come from the intermediate result in a long calculation. Whether or not x is negative may not be deducable at compile time. So it's an error, and that's EXACTLY what exceptions are for. And it will only halt the program if the exception is not caught. (Which is fair enough, I think). Anyone canny enough to wrap such calls in a try block can do their own tidy-up. And if they don't they'll get a nice error message. On the other hand, the Int class also supplies some LOW LEVEL functions. Here's one: whereby the input MUST obey (xLen >= yLen), and if it doesn't then it's a bug on the part of the caller. The assert tells whoever wrote the calling function to fix /their/ bug. This sort of thing I only ever do on seriously low level code, at the pointer and buffer level, where undefined behavior is the guaranteed result of naff input. As Norbert (I think) said, an "in" condition is part of the function's interface. So what do YOU think is the correct thing to do then, in both of these circumstances? And when exactly would you throw an exception? Note that the phrase "exceptional conditions, i.e failures" is nonsense, since "exceptional conditions" does NOT mean the same thing as "failures". (The Latin abbreviation i.e. stands for "id est", which means "that is", "that is to say", or "in other words"). They're called "Exceptions" because they happen in exceptional (that is, rare, uncommon) circumstances. They're not called "Failures", a word which means something completely different. Perhaps you could clarify your meaning? Arcane Jill
Jul 14 2004
next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:cd35jt$1fll$1 digitaldaemon.com...
 In article <cd33r9$1cjn$1 digitaldaemon.com>, Arcane Jill says...
In article <cd2rij$tra$1 digitaldaemon.com>, Matthew says...

I don't agree. Exceptions are for exceptional conditions, i.e failures, not
human
errors. If you want to be "strict", then the right thing to do when a DbC
condition is violated is to halt. An exception is not the appropriate
response.
Eh?
So what's wrong with this then? An assert is DEFINITELY not the right thing here. The input could come from the intermediate result in a long calculation. Whether or not x is negative may not be deducable at compile time. So it's an error, and that's EXACTLY what exceptions are for.
You're making assertions here (pardon the pun) that totally miss the point. An assertion is a contract enforcement. Failure to meet the contract should result in failure. In the code above you would, one might hope, document that your sqrt function is happy to receive -ve values, in which case sqrt will throw an IntException. Given that, throwing the exception is valid. If I was writing it, I would have it as part of sqrt's precondition that x>=0. Thus, if x < 0, I would issue an assertion (in the broad sense of the term, not necessarily do assert()), and the process would halt. So, your assertion that "An assert is DEFINITELY not the right thing here" is only correct if you stipulate that -ve values are valid wrt to the contract for sqrt. If that's not the case, then it's just hot air, and your shouting is crass.
 And it will only halt the program if the exception is not caught. (Which is
fair
 enough, I think). Anyone canny enough to wrap such calls in a try block can do
 their own tidy-up. And if they don't they'll get a nice error message.
And imagine all the nice extra code doing all this defensive programming. Yummy! I can only recommend you read Meyers book. A strong indication of the quality of the work is the degree to which it has influenced Walter's thinking (something notoriously difficult to do) despite the fact that he slags Walter off in Chapter 14.
 On the other hand, the Int class also supplies some LOW LEVEL functions. Here's
 one:







 whereby the input MUST obey (xLen >= yLen), and if it doesn't then it's a bug
on
 the part of the caller. The assert tells whoever wrote the calling function to
 fix /their/ bug. This sort of thing I only ever do on seriously low level code,
 at the pointer and buffer level, where undefined behavior is the guaranteed
 result of naff input. As Norbert (I think) said, an "in" condition is part of
 the function's interface.

 So what do YOU think is the correct thing to do then, in both of these
 circumstances? And when exactly would you throw an exception?
I can't be bothered to plough through all the shouting in the second one, but I can tell you I'd make the function conform to its contract.
 Note that the phrase "exceptional conditions, i.e failures" is nonsense, since
 "exceptional conditions" does NOT mean the same thing as "failures". (The Latin
 abbreviation i.e. stands for "id est", which means "that is", "that is to say",
 or "in other words"). They're called "Exceptions" because they happen in
 exceptional (that is, rare, uncommon) circumstances. They're not called
 "Failures", a word which means something completely different. Perhaps you
could
 clarify your meaning?
Jul 14 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
Firstly, I don't read Arcane Jills caps to be shouting but rather emphasis 
of key/important words. I use things like *this* to mean emphasis, Jill 
uses THIS, I can handle both.

Secondly, lets take a step back and look at this with a broader example..

Say I write a word processor, say I use your recls code to list files in a 
directory, say the user specifies a path, I don't check thier input, and 
call a fn in your API with an invalid parameter.

You API will assert, my app will terminate, the user will loose their 
work.

This is not a good outcome.

Should I have checked the parameter I passed to you? Perhaps, that is one 
solution, assuming I did that, now my program checks the parameter, and 
then so does your API call, so we're checking something twice, what is the 
point of the seccond check?

Obviously the seccond check is required, your API needs to ensure it's 
input is not erroneous, so then I ask what is the point of the first check?

So we're back to not checking the input, but, we cannot have the app 
asserting and loosing the users work. *If* your assert was an exception I 
could catch it, give an error to the user and continue. The exception 
gives me the *user* of your API the choice.

I think I'll grab a copy of "Meyers book" what is it's title? (It must be 
here somewhere but I can't find it)

I typically only use asserts for internal functions/methods, ones that are 
*not* published in my API. To me asserts represent bugs/failures in my 
API, not in it's use.

Regan.

On Wed, 14 Jul 2004 21:47:06 +1000, Matthew 
<admin stlsoft.dot.dot.dot.dot.org> wrote:
 "Arcane Jill" <Arcane_member pathlink.com> wrote in message
 news:cd35jt$1fll$1 digitaldaemon.com...
 In article <cd33r9$1cjn$1 digitaldaemon.com>, Arcane Jill says...
In article <cd2rij$tra$1 digitaldaemon.com>, Matthew says...

I don't agree. Exceptions are for exceptional conditions, i.e 
failures, not
human
errors. If you want to be "strict", then the right thing to do when a 
DbC
condition is violated is to halt. An exception is not the appropriate
response.
Eh?
So what's wrong with this then? 0"); An assert is DEFINITELY not the right thing here. The input could come from the intermediate result in a long calculation. Whether or not x is negative may not be deducable at compile time. So it's an error, and that's EXACTLY what exceptions are for.
You're making assertions here (pardon the pun) that totally miss the point. An assertion is a contract enforcement. Failure to meet the contract should result in failure. In the code above you would, one might hope, document that your sqrt function is happy to receive -ve values, in which case sqrt will throw an IntException. Given that, throwing the exception is valid. If I was writing it, I would have it as part of sqrt's precondition that x>=0. Thus, if x < 0, I would issue an assertion (in the broad sense of the term, not necessarily do assert()), and the process would halt. So, your assertion that "An assert is DEFINITELY not the right thing here" is only correct if you stipulate that -ve values are valid wrt to the contract for sqrt. If that's not the case, then it's just hot air, and your shouting is crass.
 And it will only halt the program if the exception is not caught. 
 (Which is
fair
 enough, I think). Anyone canny enough to wrap such calls in a try block 
 can do
 their own tidy-up. And if they don't they'll get a nice error message.
And imagine all the nice extra code doing all this defensive programming. Yummy! I can only recommend you read Meyers book. A strong indication of the quality of the work is the degree to which it has influenced Walter's thinking (something notoriously difficult to do) despite the fact that he slags Walter off in Chapter 14.
 On the other hand, the Int class also supplies some LOW LEVEL 
 functions. Here's
 one:







 whereby the input MUST obey (xLen >= yLen), and if it doesn't then it's 
 a bug
on
 the part of the caller. The assert tells whoever wrote the calling 
 function to
 fix /their/ bug. This sort of thing I only ever do on seriously low 
 level code,
 at the pointer and buffer level, where undefined behavior is the 
 guaranteed
 result of naff input. As Norbert (I think) said, an "in" condition is 
 part of
 the function's interface.

 So what do YOU think is the correct thing to do then, in both of these
 circumstances? And when exactly would you throw an exception?
I can't be bothered to plough through all the shouting in the second one, but I can tell you I'd make the function conform to its contract.
 Note that the phrase "exceptional conditions, i.e failures" is 
 nonsense, since
 "exceptional conditions" does NOT mean the same thing as "failures". 
 (The Latin
 abbreviation i.e. stands for "id est", which means "that is", "that is 
 to say",
 or "in other words"). They're called "Exceptions" because they happen in
 exceptional (that is, rare, uncommon) circumstances. They're not called
 "Failures", a word which means something completely different. Perhaps 
 you
could
 clarify your meaning?
-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 14 2004
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsa5ilho05a2sq9 digitalmars.com...
 Firstly, I don't read Arcane Jills caps to be shouting but rather emphasis
 of key/important words. I use things like *this* to mean emphasis, Jill
 uses THIS, I can handle both.
Ok. I understand that netiquette decreed - and I've been served many rebukes from C++ gliterrati who enjoy pointing out e-manners more than they like debating how many empty bases you can stuff onto the head of a pin - that _this is emphasis_ *this is a bit of a raised voice* THIS IS SHOUTING and, furthermore, that *this* may be interpreted as aggressive and THIS most certainly is aggresive. Oh well, hay ho!
 Secondly, lets take a step back and look at this with a broader example..

 Say I write a word processor, say I use your recls code to list files in a
 directory,
You cunning dog. You know a little flattery with recharge my battery. ;)
 say the user specifies a path, I don't check thier input, and
 call a fn in your API with an invalid parameter.

 You API will assert, my app will terminate, the user will loose their
 work.
Assuming you've passed in something that violates the pre-condition, yes. (Although, recls does not assert on invalid patterns or directories, it returns a status code indicating such. But let's assume for the sake of argument.)
 This is not a good outcome.
Agreed.
 Should I have checked the parameter I passed to you? Perhaps, that is one
 solution, assuming I did that, now my program checks the parameter, and
 then so does your API call, so we're checking something twice, what is the
 point of the seccond check?
[Meyer1997]: "Assertions are not an input checking mechanism" And I never use them as such. However, I need to qualify that. In STLSoft there are some assertions for pre-condition checking that masquerade as input validation. That's an aide d'discoverbilitae (apologies to any French speakers for my bastardisation). We have a similar thing in much of Phobos, where the in{} clause checks that something's not null. This is acceptable because both D and C/C++ have it as part of their culture that libraries may expect their clients to be correct. Were this not the case, then we're in the fat realm of the defensive programmer. In other words C/C++/D (can, they don't always do so) sacrifice DbC for release mode for the sake of efficiency. In and of itself, this does not negate the legitimacy of DbC, and all its ramifications. In practical terms, it simply means that the process will crash. Since a "caught" violation of a DbC contract is a halt, albeit one with some kind of message, the "uncaught" crash remains faithful to the cause. So, now that we've got that out of the way, we can look again at your concerns ...
 Obviously the seccond check is required, your API needs to ensure it's
 input is not erroneous, so then I ask what is the point of the first check?
One is user input validation, the other is contract enforcement. Consider the main entry function, Recls_Search() RECLS_FNDECL(recls_rc_t) Recls_Search( recls_char_t const *searchRoot , recls_char_t const *pattern , recls_uint32_t flags , hrecls_t *phSrch); Now, the contract for this function stipulates that it accepts NULL for searchRoot and for pattern. This means, respectively, to use the current directory, and to search for all files. Conversely, the contract stipulates that phSrch is *not* NULL. There is an assertion to that effect. Thus, if you pass a null pointer to Recls_Search, then you're going to get a halt, one way or another. In debug mode, you'll have a nice assertion and receive (since this is C/C++, not D) "Assertion failure: ...\recls_api.cpp(161): NULL != phSrch", or something similar. In release mode your halt will be less glamorous, since two lines later we have the statement "*phSrch = static_cast<hrecls_t>(0);" Now, one can certainly write defensively and test for phSrch. I used to do a lot more of that than I do now. Aside from the tedium, there are very good reasons why this is a "bad thing". Meyers goes through this in detail. For me there are three reasons. First it's more effort. Second you tend not to catch errors (by which I mean human coding errors, not exceptions) anywhere near as you might - your development time increases. Third, the locality of an error is lost, making tracking down a non-functioning application _far_ harder. I promise you that over the last few years when I've got less defensive, and more "aggresive", my coding time has dropped enormously, and application robustness has increased significantly.
 So we're back to not checking the input, but, we cannot have the app
 asserting and loosing the users work. *If* your assert was an exception I
 could catch it, give an error to the user and continue. The exception
 gives me the *user* of your API the choice.

 I think I'll grab a copy of "Meyers book" what is it's title? (It must be
 here somewhere but I can't find it)
"Object Oriented Software Construction" (Prentice-Hall) Be sure to write to him that it's a nice book, but you think Walter kicks his butt. ;)
 I typically only use asserts for internal functions/methods, ones that are
 *not* published in my API. To me asserts represent bugs/failures in my
 API, not in it's use.

 Regan.

 On Wed, 14 Jul 2004 21:47:06 +1000, Matthew
 <admin stlsoft.dot.dot.dot.dot.org> wrote:
 "Arcane Jill" <Arcane_member pathlink.com> wrote in message
 news:cd35jt$1fll$1 digitaldaemon.com...
 In article <cd33r9$1cjn$1 digitaldaemon.com>, Arcane Jill says...
In article <cd2rij$tra$1 digitaldaemon.com>, Matthew says...

I don't agree. Exceptions are for exceptional conditions, i.e
failures, not
human
errors. If you want to be "strict", then the right thing to do when a
DbC
condition is violated is to halt. An exception is not the appropriate
response.
Eh?
So what's wrong with this then? 0"); An assert is DEFINITELY not the right thing here. The input could come from the intermediate result in a long calculation. Whether or not x is negative may not be deducable at compile time. So it's an error, and that's EXACTLY what exceptions are for.
You're making assertions here (pardon the pun) that totally miss the point. An assertion is a contract enforcement. Failure to meet the contract should result in failure. In the code above you would, one might hope, document that your sqrt function is happy to receive -ve values, in which case sqrt will throw an IntException. Given that, throwing the exception is valid. If I was writing it, I would have it as part of sqrt's precondition that x>=0. Thus, if x < 0, I would issue an assertion (in the broad sense of the term, not necessarily do assert()), and the process would halt. So, your assertion that "An assert is DEFINITELY not the right thing here" is only correct if you stipulate that -ve values are valid wrt to the contract for sqrt. If that's not the case, then it's just hot air, and your shouting is crass.
 And it will only halt the program if the exception is not caught.
 (Which is
fair
 enough, I think). Anyone canny enough to wrap such calls in a try block
 can do
 their own tidy-up. And if they don't they'll get a nice error message.
And imagine all the nice extra code doing all this defensive programming. Yummy! I can only recommend you read Meyers book. A strong indication of the quality of the work is the degree to which it has influenced Walter's thinking (something notoriously difficult to do) despite the fact that he slags Walter off in Chapter 14.
 On the other hand, the Int class also supplies some LOW LEVEL
 functions. Here's
 one:







 whereby the input MUST obey (xLen >= yLen), and if it doesn't then it's
 a bug
on
 the part of the caller. The assert tells whoever wrote the calling
 function to
 fix /their/ bug. This sort of thing I only ever do on seriously low
 level code,
 at the pointer and buffer level, where undefined behavior is the
 guaranteed
 result of naff input. As Norbert (I think) said, an "in" condition is
 part of
 the function's interface.

 So what do YOU think is the correct thing to do then, in both of these
 circumstances? And when exactly would you throw an exception?
I can't be bothered to plough through all the shouting in the second one, but I can tell you I'd make the function conform to its contract.
 Note that the phrase "exceptional conditions, i.e failures" is
 nonsense, since
 "exceptional conditions" does NOT mean the same thing as "failures".
 (The Latin
 abbreviation i.e. stands for "id est", which means "that is", "that is
 to say",
 or "in other words"). They're called "Exceptions" because they happen in
 exceptional (that is, rare, uncommon) circumstances. They're not called
 "Failures", a word which means something completely different. Perhaps
 you
could
 clarify your meaning?
-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 14 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Thu, 15 Jul 2004 10:15:09 +1000, Matthew 
<admin stlsoft.dot.dot.dot.dot.org> wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsa5ilho05a2sq9 digitalmars.com...
 Firstly, I don't read Arcane Jills caps to be shouting but rather 
 emphasis
 of key/important words. I use things like *this* to mean emphasis, Jill
 uses THIS, I can handle both.
Ok. I understand that netiquette decreed - and I've been served many rebukes from C++ gliterrati who enjoy pointing out e-manners more than they like debating how many empty bases you can stuff onto the head of a pin - that _this is emphasis_ *this is a bit of a raised voice* THIS IS SHOUTING and, furthermore, that *this* may be interpreted as aggressive and THIS most certainly is aggresive. Oh well, hay ho!
I find myself using both *this* and THIS to mean emphasis, I did not even know _this_ existed, you learn something new every day. I'll _try_ and change my habits :)
 Secondly, lets take a step back and look at this with a broader 
 example..

 Say I write a word processor, say I use your recls code to list files 
 in a
 directory,
You cunning dog. You know a little flattery with recharge my battery. ;)
:) It seemed as good an example as any other. To tell the truth I have not had cause to use it, yet.
 say the user specifies a path, I don't check thier input, and
 call a fn in your API with an invalid parameter.

 You API will assert, my app will terminate, the user will loose their
 work.
Assuming you've passed in something that violates the pre-condition, yes.
"invalid parameter" to me means "violates the pre-condition"
 (Although, recls does not assert on invalid patterns or directories, it 
 returns a
 status code indicating such. But let's assume for the sake of argument.)

 This is not a good outcome.
Agreed.
Funny how everyone agrees on the end result, just not how to get there.
 Should I have checked the parameter I passed to you? Perhaps, that is 
 one
 solution, assuming I did that, now my program checks the parameter, and
 then so does your API call, so we're checking something twice, what is 
 the
 point of the seccond check?
[Meyer1997]: "Assertions are not an input checking mechanism" And I never use them as such. However, I need to qualify that. In STLSoft there are some assertions for pre-condition checking that masquerade as input validation. That's an aide d'discoverbilitae (apologies to any French speakers for my bastardisation). We have a similar thing in much of Phobos, where the in{} clause checks that something's not null. This is acceptable because both D and C/C++ have it as part of their culture that libraries may expect their clients to be correct.
That does not make it 'good' only 'consistent'.
 Were this
 not the case, then we're in the fat realm of the defensive programmer.
I was once told to program my APIs as if my input was from a 'half sane monkey on crack' I guess that makes me a defensive programmer.
 In other words C/C++/D (can, they don't always do so) sacrifice DbC for 
 release
 mode for the sake of efficiency.
I can understand that, however IMO you cannot possibly find/catch _all_ the bugs in debug mode/testing. So some will creep thru into the relase build. Who cares how fast it runs if it's gonna crash? Your program will simply crash faster.
 In and of itself, this does not negate the
 legitimacy of DbC, and all its ramifications. In practical terms, it 
 simply means
 that the process will crash. Since a "caught" violation of a DbC 
 contract is a
 halt, albeit one with some kind of message, the "uncaught" crash remains 
 faithful
 to the cause.
I don't think I like this cause, it casues: - me to rely on the OS for a backtrace to find my bugs - the user to loose thier work. An exception solves the above problems.
 So, now that we've got that out of the way, we can look again at your 
 concerns
 ...

 Obviously the seccond check is required, your API needs to ensure it's
 input is not erroneous, so then I ask what is the point of the first 
 check?
One is user input validation, the other is contract enforcement.
I think your "contract enforcement" is simply another way of saying "input checking" which would mean you were breaking Meyers rule: "Assertions are not an input checking mechanism" Perhaps the above rule when it refers to 'input' is referring to 'end user' input? Using your example below, in _most_ cases the phSrch parameter will _not_ be affected by user input, meaning, so long as the developer passes one they'll never see the assert. And if they fail to pass one they'll see the assert once causing them to pass one in future. However, if it were affected by user input then you would not want an assert, you'd want an exception. I could dream up some buggy code where this is the case but I believe you can imagine it too. So whether you want to assert or throw an exception is based on the program calling your API, your API cannot possibly make this choice. By using an assert here, you're either: - achieving nothing (the developer never sees it, or sees it once) - causing problems (the app terminates the user loose their work) Given that, API input _must_ be treated as end user input and thus you cannot use assertions.
 Consider the
 main entry function, Recls_Search()

 RECLS_FNDECL(recls_rc_t) Recls_Search(  recls_char_t const  *searchRoot
                                     ,   recls_char_t const  *pattern
                                     ,   recls_uint32_t      flags
                                     ,   hrecls_t            *phSrch);

 Now, the contract for this function stipulates that it accepts NULL for
 searchRoot and for pattern. This means, respectively, to use the current
 directory, and to search for all files.

 Conversely, the contract stipulates that phSrch is *not* NULL. There is 
 an
 assertion to that effect.
It could be a InvalidParameterException instead.
 Thus, if you pass a null pointer to Recls_Search, then you're going to 
 get a
 halt, one way or another. In debug mode, you'll have a nice assertion 
 and receive
 (since this is C/C++, not D) "Assertion failure: ...\recls_api.cpp(161): 
 NULL !=
 phSrch", or something similar. In release mode your halt will be less 
 glamorous,
 since two lines later we have the statement "*phSrch = 
 static_cast<hrecls_t>(0);"
If it was an exception you could get it in both debug and release modes. You would not get a crash. The user would not loose their work.
 Now, one can certainly write defensively and test for phSrch. I used to 
 do a lot
 more of that than I do now. Aside from the tedium, there are very good 
 reasons
 why this is a "bad thing". Meyers goes through this in detail. For me 
 there are
 three reasons. First it's more effort.
Nothing is free, stability costs development time and effort.
 Second you tend not to catch errors (by
 which I mean human coding errors, not exceptions) anywhere near as you 
 might -
 your development time increases.
An exception will still catch human coding errors. Their development time will not change. Yours wont either, you just code "throw.." instead of "assert(.."
 Third, the locality of an error is lost, making
 tracking down a non-functioning application _far_ harder.
Why? Assuming exceptions have access to __FILE__ and __LINE__ (or their D equivalent) then you get just as much from them as an assert. This is the change I think we _need_. If __FILE__ and __LINE__ are only available in debug mode (which seems likely) an exception is still better than an assert as you can place any text you want in one. I know, this is what you're asking to be added to asserts, to me that suggests you want to use an exception instead.
 I promise you that over
 the last few years when I've got less defensive, and more "aggresive", 
 my coding
 time has dropped enormously, and application robustness has increased
 significantly.
I cannot confirm or deny that. ;) Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 14 2004
parent "Bent Rasmussen" <exo bent-rasmussen.info> writes:
 Perhaps the above rule when it refers to 'input' is referring to 'end
 user' input?
That what it refers to. Its not input from some function that is part of your program/system -- contracts works to make them correct, its input from some human or from outside the system where no correctness can be assumed -- you can't debug a human into allways inputting a correct e-mail address. :-) You can't ever assume "my users will input a correct e-mail address." So, the rule is - "defensive" for user-module messages (forms, files, etc.) - "offensive" for inter-module messages My guess is that a contract syntax motivates setting up traps against coding errors more than using exceptions do. Not that exceptions don't have their place. Its also nice to read a specification with concise and precise contracts. I can also recommend Object-Oriented Software Construction, its a great book; and also looking at EiffelSoft code for examples of contracts. In fact, some weeks ago I stumbled upon this link which may be a good introduction to contracts http://www.eiffel.com/developers/presentations/
Jul 15 2004
prev sibling next sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
Arcane Jill wrote:

In article <cd33r9$1cjn$1 digitaldaemon.com>, Arcane Jill says...
  

In article <cd2rij$tra$1 digitaldaemon.com>, Matthew says...

    

I don't agree. Exceptions are for exceptional conditions, i.e failures, not
human
errors. If you want to be "strict", then the right thing to do when a DbC
condition is violated is to halt. An exception is not the appropriate response.
      
Eh?
So what's wrong with this then? An assert is DEFINITELY not the right thing here. The input could come from the intermediate result in a long calculation. Whether or not x is negative may not be deducable at compile time. So it's an error, and that's EXACTLY what exceptions are for.
I would be fired on the spot if I wrote code like that in my industry. For a small function like sqrt, you don't want the extra overhead of exceptions in a release versions of the code. It really is an error on the caller, its not the sqrts fault that such a value was passed in. Assertions are about contracts, making sure the pre and post conditions are correct. Exceptions are about handling errors that arise in the code that you may not be there to fix when they occur. -- -Anderson: http://badmama.com.au/~anderson/
Jul 14 2004
prev sibling parent reply "Bent Rasmussen" <exo bent-rasmussen.info> writes:
 So what's wrong with this then?




0");


I interpret assertions as a subtyping mechanism. E.g. the expression x >= 0 is an implicit construction of the type "natural", on a conceptual level. Its not as safe as compile time checking but useful nonetheless. It seems appropriate to use an assertion here. Defensive programming still has its place and probably beyond input validation for critical systems; no experience there though. :-) I don't know though, if it is possible to catch an assertion violation as an exception. That appears to be useful to me. Then if an assertion violation is caught then the assertion would not be turned off in the release build. But since assertions have no labels in D, it wouldn't be possible to catch a particular assertion violation, e.g. as in sqrt(Int x): Int require natural: x >= x.Zero Just a thought...
Jul 15 2004
parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"Bent Rasmussen" <exo bent-rasmussen.info> escribió en el mensaje
news:cd6nm7$2ddq$1 digitaldaemon.com
| I interpret assertions as a subtyping mechanism. E.g. the expression
|
|     x >= 0
|
| is an implicit construction of the type "natural", on a conceptual level.
| Its not as safe as compile time checking but useful nonetheless.
|

read below

| It seems appropriate to use an assertion here. Defensive programming still
| has its place and probably beyond input validation for critical systems;
no
| experience there though. :-)
|
| I don't know though, if it is possible to catch an assertion violation as
an
| exception. That appears to be useful to me. Then if an assertion violation
| is caught then the assertion would not be turned off in the release build.
| But since assertions have no labels in D, it wouldn't be possible to catch
a
| particular assertion violation, e.g. as in
|
|     sqrt(Int x): Int
|         require
|             natural: x >= x.Zero
|
| Just a thought...

It'd be better (and easier for the programmers) if D had ranges. Then you
would declare your own natural type with that condition. And it'd be compile
time.

-----------------------
Carlos Santander Bernal
Jul 15 2004
next sibling parent "Bent Rasmussen" <exo bent-rasmussen.info> writes:
 It'd be better (and easier for the programmers) if D had ranges. Then you
 would declare your own natural type with that condition. And it'd be
compile
 time.
It would indeed. That's one of the things I liked when I saw some Pascal code awhile ago. It probably wouldn't extend well beyond primitive types though.
Jul 15 2004
prev sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
Carlos Santander B. wrote:

"Bent Rasmussen" <exo bent-rasmussen.info> escribió en el mensaje
news:cd6nm7$2ddq$1 digitaldaemon.com
| I interpret assertions as a subtyping mechanism. E.g. the expression
|
|     x >= 0
|
| is an implicit construction of the type "natural", on a conceptual level.
| Its not as safe as compile time checking but useful nonetheless.
|

read below

| It seems appropriate to use an assertion here. Defensive programming still
| has its place and probably beyond input validation for critical systems;
no
| experience there though. :-)
|
| I don't know though, if it is possible to catch an assertion violation as
an
| exception. That appears to be useful to me. Then if an assertion violation
| is caught then the assertion would not be turned off in the release build.
| But since assertions have no labels in D, it wouldn't be possible to catch
a
| particular assertion violation, e.g. as in
|
|     sqrt(Int x): Int
|         require
|             natural: x >= x.Zero
|
| Just a thought...

It'd be better (and easier for the programmers) if D had ranges. Then you
would declare your own natural type with that condition. And it'd be compile
time.

-----------------------
Carlos Santander Bernal


  
Agreed, its one of the things I liked about ada. -- -Anderson: http://badmama.com.au/~anderson/
Jul 16 2004
prev sibling parent Richard Krehbiel <rich kastle.com> writes:
Matthew Wilson wrote:
 Can I register yet another request for this long-looked-for feature?
 
 I'm finding it rather painful that the output just prints "Error:
 AssertError Failure vector(390)". It's just a PITA.
 
 Can we get this for 1.0?
 
 
You can do it right now. #define ASSERT(x) if(!(x)) __assert_fail("Assertion failed: " ~ #x); And then, pass your D source thru your favorite C preprocessor first. (You don't have to avoid CPP. There's nothing wrong with it.)
Jul 16 2004