crypted\dynloader.d(11): Throw statements cannot be in contracts

"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

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

"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

"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

"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