🚀 go-pugleaf

In article <3188@osc.COM> jgk@osc.COM (Joe Keane) writes:
>
>	Suppose we're in a language with real exception handling.
>	It's only a matter of terminology whether you count an exception
>	as a kind of return value, a side effect, or something different.

>	In particular, defining errors to be the same as bottom
>	is an unwise thing to do ...

If you "handle" an exception then it is no longer an error
-- just another possible result.  Semantically speaking,
an error is an _unhandled_ exception.  Since it is unhandled,
why not declare the result to be `undefined' (i.e. is bottom)?

Make an analogy with mathamatics.  Consider the function f(x) = 5/x.
What is the value of the function at x=0?  `Error' or `undefined'?

It is a design issue as to whether you make the programmer
handle exceptions explicitly, or whether the language implicitly
tacks on exception-handling routines.  I have no argument
with those who advocate implicit exception-handling mechanisms
(though the increased expressiveness requires a more complicated language).

	Frank Silbermann	fs@rex.cs.tulane.edu