www.digitalmars.com         C & C++   DMDScript  

D - Why can I put an assert in an 'out' clock but not a throw ?

reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
crypted\dynloader.d(11): Throw statements cannot be in contracts
Feb 08 2003
parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Mike Wynn" <mike.wynn l8night.co.uk> escreveu na mensagem
news:b241lv$1cro$1 digitaldaemon.com...
 crypted\dynloader.d(11): Throw statements cannot be in contracts
Hi, Contracts should be used to specify correctness of certain pieces of code (e.g. methods or class invariants). The client of the service (e.g. the caller of the method) should be able to verify the conditions before using the service, to ensure he meets all preconditions stated. If a contract contains throw statements, the client may be in trouble trying to ensure he meets all preconditions before calling the method. Also contracts should never have side-effects, so the compiler may remove them automatically if the programmer requests it, or if it can verify the correctness of the call, or the algorithm (if it's a postcondition or a invariant). The assert is used to identify logical errors in your code, almost like compiler errors. I don't know why you want to throw a particular exception, instead of using a simple assert, but I can think of two reasons: 1 - You want to call the code inside a try/catch block, so the caller can catch the exception and do something with this information. Don't. Try to provide a way for your client to verify the contract correctness instead. If your function isn't total (i.e.: for some parameter values it can't produce a valid answer) try to return an invalid value (e.g. null or a subtype). 2 - You want to pass more information than "Assertion Error", so you don't need to reproduce the error while debugging the code to verify the state of the system. This is a good use for a specialized exception, but I think it should be better if assertion errors gave access to stack information (like Eiffel does) and the assert keyword could be associated with an error message. If you're doing 2 IMHO you should create a dummy function that throw the exception and call it instead of throwing the exception directly. There's always a trick available to fool the compiler ;-) Best regards, Daniel Yokomiso. "We all begin life naked, covered in blood, and screaming. But if we live right, it doesn't have to stop there." - Robert A. Heinlein --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003
Feb 08 2003
parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:b24723$1fhm$1 digitaldaemon.com...
 "Mike Wynn" <mike.wynn l8night.co.uk> escreveu na mensagem
 news:b241lv$1cro$1 digitaldaemon.com...
 crypted\dynloader.d(11): Throw statements cannot be in contracts
2 - You want to pass more information than "Assertion Error", so you don't need to reproduce the error while debugging the code to verify the state
of
 the system. This is a good use for a specialized exception, but I think it
 should be better if assertion errors gave access to stack information
(like
 Eiffel does) and the assert keyword could be associated with an error
 message.

     If you're doing 2 IMHO you should create a dummy function that throw
the
 exception and call it instead of throwing the exception directly. There's
 always a trick available to fool the compiler ;-)
yes it was so I could assert with my own message and I second your request for stack traces in Exceptions and asserts, I did a lot of Java programming, and found it very handy and I don't believe that it's a performance issue, you (any one who is) should not be using exceptions as long jump or switch on type. (no matter how neat it seems). exceptions are for exceptional conditions, if they get thrown then somethings wrong, and gathering up a stack trace even if it takes a few seconds is accept able for the benifits it gives. my point was also "if I can do X by fooling the compile why can't I do X"
Feb 08 2003
next sibling parent reply Antti Sykari <jsykari gamma.hut.fi> writes:
"Mike Wynn" <mike.wynn l8night.co.uk> writes:

 my point was also "if I can do X by fooling the compile why can't I do X"
This is, IMO, the primary reason why throwing in contract clauses should be allowed. Either disallow it completely or allow it, but don't force the programmer to kludge himself around it. As assertions are already implemented with the Assert exception (phobos/a.d), it would probably be reasonable to assume that you could throw subclasses of Assert? (By the way, dbc.html in the D web documentation still refers to AssertException - should this be just Assert?) -Antti
Feb 09 2003
parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Antti Sykari" <jsykari gamma.hut.fi> escreveu na mensagem
news:86of5lg0d5.fsf hoastest1-8c.hoasnet.inet.fi...
 "Mike Wynn" <mike.wynn l8night.co.uk> writes:

 my point was also "if I can do X by fooling the compile why can't I do
X"
 This is, IMO, the primary reason why throwing in contract clauses
 should be allowed.  Either disallow it completely or allow it, but
 don't force the programmer to kludge himself around it.
We need to hack around it only because the compiler is still growing, and this kind of feature wasn't implemented. But contracts should not be recoverable, or throw exceptions.
 As assertions are already implemented with the Assert exception
 (phobos/a.d), it would probably be reasonable to assume that you could
 throw subclasses of Assert?

 (By the way, dbc.html in the D web documentation still refers to
 AssertException - should this be just Assert?)

 -Antti
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003
Feb 09 2003
prev sibling parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Mike Wynn" <mike.wynn l8night.co.uk> escreveu na mensagem
news:b2488t$1g13$1 digitaldaemon.com...
 "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
 news:b24723$1fhm$1 digitaldaemon.com...
 "Mike Wynn" <mike.wynn l8night.co.uk> escreveu na mensagem
 news:b241lv$1cro$1 digitaldaemon.com...
 crypted\dynloader.d(11): Throw statements cannot be in contracts
2 - You want to pass more information than "Assertion Error", so you
don't
 need to reproduce the error while debugging the code to verify the state
of
 the system. This is a good use for a specialized exception, but I think
it
 should be better if assertion errors gave access to stack information
(like
 Eiffel does) and the assert keyword could be associated with an error
 message.

     If you're doing 2 IMHO you should create a dummy function that throw
the
 exception and call it instead of throwing the exception directly.
There's
 always a trick available to fool the compiler ;-)
yes it was so I could assert with my own message and I second your request for stack traces in Exceptions and asserts, I
did
 a lot of Java programming, and found it very handy
 and I don't believe that it's a performance issue, you (any one who is)
 should not be using exceptions as long jump or switch on type. (no matter
 how neat it seems).
 exceptions are for exceptional conditions, if they get thrown then
 somethings wrong, and gathering up a stack trace even if it takes a few
 seconds is accept able for the benifits it gives.
There are two different things here: assertion errors and exceptions. Both can be more useful if stack trace information is provided, but each at a different level. Java stack trace information for exceptions includes the method call hierarchy (usually with file lines included). Eiffel provides not only the methods called, but the environment too (values of objects in the stack). IMO D should support both things, one for exceptions (Java-like) and one for assertion errors (Eiffel-like), because they're different things. Assertion errors should never be trapped, while exceptions should always be handled somewhere. It's the fundamental difference between errors (things you can't recover, either system errors (e.g. run out of memory) or programming errors (e.g. index out of bounds)) and exceptions (conditions that are expected to have exceptional cases).
 my point was also "if I can do X by fooling the compile why can't I do X"
We only need to fool the compiler because current dmd implementation doesn't offer us more information. But this should not be a common practice. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003
Feb 09 2003