🚀 go-pugleaf

In article <BEVAN.92Sep29181450@tiger.cs.man.ac.uk>, bevan@cs.man.ac.uk (Stephen J Bevan) writes:

>From the examples given, it seems we have fundamentally different
>ideas about what an "exception" actually is.

It wouldn't surprise me, I've been working on the concepts myself and I've
come to a few conclusions that may not be very mainstream.

>                                             For example, when
>reading characters from a file, I do not consider reaching the end
>of the file as an exceptional condition

You can consider it however you like, but it seems to _me_ that reading EOF
is _certainly_ an exception.  You seldom just process the character like
any other, and you certainly can't read any more, so you have to do _something_
different, and that's an exception to your normal file-reading routine.
Exceptions just mean "not normal in this context".  In a file-reading loop,
EOF is certainly not normal.  That _doesn't_ mean "random", it's quite
predictable and we need to be able to handle it, but it is incidental
to the workings of the loop and hence, exceptional.

>                                        and I certainly don't like the
>idea of using an exception to terminate an iteration over a fixed
>range.

How is this fundamentally different?  Any safe language _must_ make those
checks anyway, making them in the loop control is just redundant.  Either you
waste processing time or you need a compiler smart enough to optimize away
it's own checks if the program already does them.  But the _extent_ of a loop
is really just minutia, and in order to code it you need to know the size of
the array.  With exceptions, you just start looping and trust the runtime
system to kick you out when you are done.  You need fewer explicit variables,
and you don't need a parameter to the loop.  You simplify the compiler, and
remove the need for optimizing and still serve the needs of safety.  Yes,
it requires a different mindset.  But it still looks like a win to me.

>       IMHO exceptions can be replaced by either making a function
>take/return additional arguments or by dynamically binding a function
>to be called in the event of an "exception".

That requires additional code.  Yes, it can work (and I've used it many times
in C++ and other languages - especially Modula2), but you must still define
your exception handler as another routine, which requires that it have a new
name (namespace pollution is becoming more of a concern every year).  Further-
more, you can't nest environments without explicitly coding some sort of
handler stack.  Even so, if it were possible to get the effect I have in mind
_within_ the language, I'd agree with you, but you can't.  Even if you call
a handler, it still going to return_to_the_function_that_detected_the_problem.
It cannot abort processing and roll the stack back to a known state, as an
exception can.  If your file reader called a handler at EOF, that handler can
set booleans, close the file, do whatever, but it must still return to a
routine that _must_ return some sort of result.  I hate undefined or out-of
band results.  The first is sloppy, the second requires widening data types
and making the program less type-secure.  Exceptions seem a much more
elegant mechanism.

Larry Smith (smith@ctron.com)  No, I don't speak for Cabletron.  Need you ask?
-
How about we all do something reasonable?  I bet that'll confuse 'em!