Runtime Safety of Programs

[Zuurbier, E. - AMSXE]

David McClain wrote:

>Thanks for your reply... Unfortunately in real life, I also face the
>situation of expected files that might be missing, or incorrect user input,
>or any of a number of other situations in which I would normall throw an
>exception.

This could trigger a great deal of discussion. I would certainly not
consider these
examples cases for throwing an exception. For me, a missing file or
incorrect
user input are just possible forms of a program's input, which I would
consider
in the program's main line. For me, throwing an exception is not yet another
control structure.
Now that I think of it, maybe I would particularly like exceptions handling
in cases where the
runtime system throws them, not the programmer: ''heap full', 'stack
overflow', 'cycle in spine'.
Not for division by zero, missing files, failing pattern matches,
referencing non existent array-cells.
Those situations are already under the control of the programmer with
current control
structures.

>I feel somewhat hamstrung at
>this time, however, in applying Clean to typical realworld applications
such
>as data acquisition and instrument control.

I can imagine. Currently, in Clean there is no way to deal with 'heap full'
or 'stack overflow''
situations other than to manually prove that they won't occur. If they do,
the program
aborts, which may be unacceptable in instrument control.

Erik Zuurbier