Re: Exceptions

[Quinn Dunkan]

> On Sun, Oct 01, 2000 at 04:14:48PM +0000, Lars Hupfeldt Nielsen wrote:
> > Hi,
> > 
> > I compleetely agree that exception usage in the library is not 
> > consistent. In general all errors should be exceptions. There might be  
> > a few exceptions to this rule, but there is absolutely no reason that 

Y'know... where I come from, puns like that are a shooting offense.

> After all: Exceptions are the method of choice wherever there are 
> errors that occur at runtime that can't possibly caught by the compiler 
> (IO-Errors etc) For everything else, there should theoretically be a 
> compile-time check. Anyhow, theory does not help much here, since many 
> things just cant be checked at compile time. Still pre/post-conditions 
> and assertions are a better solution here.

This actually raises (aargh!! *blam*) a question I have about DBC.  Supposing I
have:

class FILE is
    read(nchars:INT) pre is_open is
        ...
    end;
    is_open:BOOL is
        ...
    end;
    open(fname:STR) pre PATH::file_exists(fname) is
        ...
    end;
end;

Is the precondition on 'read' right or wrong?  It looks right because only a
buggy program would read after a close.  But the precondition on 'open' is
almost certainly wrong, because one frequently opens a file based on
user-input, so a perfectly ok program will often attempt to open a
non-existent file.  If the precondition is there, it will kill your whole
program.  The only way around would be to catch the AssertionError exception
(if it is one), but once you can catch assertion failures at run time you're
replacing compiler-provided safety features with your own hand-coded runtime
"safety features" which is wrong.

In the case of 'read' and 'open' the distinction is clear.  But the criterion
for the distinction: whether the precondition could *only* be violated by a
buggy program and not by user input, is not well-defined.  This means there is
*another* contract between the library and the program about what the program
is allowed to pass from the user directly to the library, and everything else
must be a bug in the program.  Is that "meta-contract" well-defined?  What
about a "meta-meta-contract"?  I'd say this means there is no way to know for
absolutely sure whether you should precondition something or not, but since
the effects of a bad precondition choice are unpleasant (forces you to
duplicate the precondition in your own code at runtime to avoid blowing the
whole program up), you shouldn't use them unless you're really sure.

But if you tend to not use them, isn't that defeating their purpose?  I guess
the answer is that the code duplication is desirable, because while both
pieces of code are performing the same check, they're doing on different
conceptual levels.  So presumably precondition-check methods shouldn't be
private because the user will want to call them himself at runtime.

So exceptions can indicate an exceptional occurrance, an error, or a bug.
Assertions can only indicate a bug.

I guess I should really read what Meyer says about this stuff.