Re: Exceptions

[Quinn Dunkan]

> On Tue, Oct 10, 2000 at 07:01:26PM +1300, Keith Hopper wrote:
> >      I wrote on exceptions to the news group a couple of days ago - but
> > they don't appear here (yet?).
> 
> I read it already. Was very conclusive!

I haven't seen it yet.  Dumb news feed.  If you tell me the title I colud look
on deja.

> >      In a nut-shell there are two possible uses of exceptions and exception
> > handling depending on your philosophy of programming :-
> > 
> > (1)  An exception is only raised when something occurs at run-time which
> > -prevents- proper termination of some method.
> > 
> > (2)  Every time that something 'unexpected' occurs use an exception.

I don't see this as being "two" possible uses.  For example, supposing you
have an ARRAY::index(elt:T):IX method, which returns the index of 'elt' in the
array.  What happens if 'elt' is not in array?  Well, the index method
obviously can't properly return an index, because there is no index!  So since
it can't terminate properly (according to its signature), it must throw an
exception.  "No 'elt' in array" is hardly unexpected, of course, so this is
clearly (1) and not (2).

On the other hand, that would be really annoying, because the 'index' method
is used very frequently to see if 'elt' is in the array at all, and exceptions
in sather involve a lot of syntax overhead (and perhaps some execution
overhead too).  So you find some ad hoc 'nil' value index can return.  It
really depends on the intended use of the method.  If you provided a
'contains(elt:T):BOOL' method, then you could expect people to use that, but
then the common case of "is it there? and if so, where is it?" will involve
two linear searches (on an unsorted array) instead of one.

python's solution, as I mentioned before, is to provide two methods equivalent
methods, one which throws and one which doesn't.  In practice, I rarely use
the one that throws.

So I'm on the side of "return some kind of nil value" purely for practical
reasons.  But each method is a special case!  If anyone has a way of
automatically determining which is "Right" for every single method, I'd like
to hear about it :)

> Why be restrictive? OK, it is one way to say: exceptions are evil, 
> prevent to use them if possible at all. Still: I consider exceptions as 
> a fundamental language feature - as long as long as it is used with 
> care!
> 
> What is lacking in Sather is a mechanism to specify which exceptions a 
> method may raise. After all, that really is part of the interface. If 
> we had such a thing, exceptions would just become a special kind of 
> return value. In many cases, there are three alternatives:

Urg... doesn't Java do that?  I've never used java, so I can't say much about
how having to declare all exceptions turns out in practice, but it seems like
it would lead to "cascading verbiage" where each method may throw any
exception any methods it call may throw, which encourages people to handle
exceptions immediately, which defeats the whole point of exceptions in the
first place.

Can't that sort of thing be inferred by the compiler?  All it has to do is see
what the current routine may throw, and if it's not caught, say the caller can
throw it too.  Then you could have a warning switch to warn about uncaught
exceptions (although in many cases, one doesn't *want* them to be caught, and
the compiler can't know the difference), or trying to catch an exception that
will never be thrown (although I've never had this problem).

> (1) Force the programmer to check for the executability of a method 
> beforehand and throw in a pre-condition.

If the assertion error in the precondition can be caught, then this seems
basically like (3).

> (2) Let the method return a special value (like "void") in case of such 
> an execution.

This means all errors must be explicitly checked for.  Every single method
that may fail must be explicitly checked for failure, or there will be a
problem somewhere down the road when someone tries to use the value.  I
thought the main point of static typing was that errors are caught as early as
possible... doesn't making extensive use of a 'void' value sort of defeat
this?  One of the many things I don't like about C is the "make a mess of your
code by checking everything or live dangerously" choice it forces you to
make.

In addition to supporting static typing, it seems like exceptions support OO
encapsulation as well: an object should determine what it's own error
reporting is, not its caller.  That way, FILE can throw
"File does not exist: foo" instead of FILE's twelve callers each reporting a
variation of "Can't find foo" "foo: No such file" etc.

> (3) Throw a well-defined exception.

Obviously this is the one I prefer :)

> In many cases those three would be interchangable. In each case, the 
> user of the method needs to know about it and handle the error-case in 
> a certain way.

Only if the user wants it to be a non-fatal error.  Many errors *are* fatal.
Assertions are among them, but there a lot of other cases.  Those exceptions
are usually handled by the runtime, which hopefully prints the name and value
of the exception and a stack trace if debugging is on.  Isn't that what
exceptions are all about? :)