[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cheerful static typing (was: Any and Every... (was: Eval))
Quoting Guy Steele - Sun Microsystems Labs:
> You should not equate "runtime error" with "throws an exception".
> Some errors do not throw exceptions, and some throws of exceptions are
> not errors. An error is when a program fails to meet its defined
> contract. If you call integer divide on 2 and 0, and it throws a
> zero-divide exception, that's not an error, because integer divide
> is obeying its contract.
> Careful, here, Dan; taking this to a logical extreme
> implies that, if you beef up the contracts, you can
> define away all errors.
It is certainly possible to make vacuous contracts that guarantee
nothing about your operation. In fact, there is one function having
that contract that I program with routinely, as a program environment
developer. It's `eval'. DrScheme (our PE) has a REPL; it reads
characters from the input, forms an s-expression from them and `eval's
it. Since eval can do just about anything, DrScheme has to handle just
about anything and report back what happened to the user of the PE.
Of course, that is not a useful contract in most cases. :)
> Maybe we could say that a run-time error is a situation
> in which a program exhibits one of a set of behaviors
> that we choose to describe as "undesirable"? Often
> throwing one of a certain set of exceptions is considered
> undesirable; indeed, the division-by-zero exception may
> be undesirable in some contexts despite the fact that
> it's in the contract of the "/" operator.
I think that what's missing here is the idea of blame. For each
contract violation there must be a guilty party and they are to be
blamed for the violation.
It is important to say that raising a divison-by-zero error is part of
the division operator's contract, so that we know that when the
exception is raised we should not blame `/'. Instead, there is some
other operation that uses `/' whose contract does not say anything
about divison by zero errors (eg, a line drawing function that may not
handle vertical lines properly). That's the one to blame.
PS: As this is my first post, let me take this chance to say that I
have really enjoyed the discussions on this list and that I wish that I
had been able to attend the workshop. Thanks very much!