[clean-list] Exceptions handling again

[Erik Zuurbier]

Jenda Krynicky wrote:
"Just a very simple example ... how would you prove that your program is
going to have enough memory?"

For most regular programs it will be hard or impossible. That's why you may
need to change (improve?) your program so that you could prove it.

Jenda Krynicky also wrote:
"Exceptions allow you to handle errors at the place where the handling
makes sense, which is not necessarily the same place the errors occur.
Exceptions usualy allow you to write much nicer code, instead of passing
some status variables around and testing them all the time you just throw
an exception and somewhere several levels up in the call stack you handle
them."

This is what we all know about exception handling. Speculative evaluation
strategies (for instance Optimistic Evaluation - described in a paper by
Robert Ennals and Simon Peyton Jones) show us that you can sometimes pursue
a line of evaluation and then, for whatever reason, stop, back out and try
something else. In my opinion, large classes of what is usually seen as
exceptions, could be handled this way: when an integer overflow is
encountered, the program could back out and retry the same calculation with
an infinite precision library.

When the language supports deterministic parallellism, as one Clean
implementation by Marco Kesseler once demonstrated, alternatives to pursue
may be more abundant.

Marco Kesseler wrote to me on 12 march 2003 (translation from Dutch):
"Say processor A assigns evaluation of an expression to processor B and
then the communication line between the two dies:
- what keeps processor A from deciding after all to evaluate the expression
itself, or assign it to processor C?
- what keeps processor B from halting evaluation of this expression and
just throwing it away? B could even use a timeout interval (the way
webservers handle sessions)."

The TCP/IP has a marvelous mechanism: if I understood it well, a sender
resends a packet if it does not get an acknowledgement back within a time
interval that depends on the mean and variance of the turn-around time
experienced sofar. It thereby strikes a balance between network load (by
minimizing the number of resends) and communication speed (by minimizing
the delay of a resend). This mechanism probably catches huge numbers of
exceptions without me knowing. But then a communication line completely
dies and this mechanism does not help a bit. I like to think the internet
has other protocols that seek alternative communication routes when that
happens.

And what does CiteSeer? It dumps an error message back on me: "Server busy.
Try later." Why should that happen? I envision a browser that catches that
one and does the try latering itself - a la the resends of TCP/IP - and I
would only see a window that is waiting for a response. In the mean time I
can work in other windows and only if/when I lose patience would I close
the CiteSeer window (withdraw the redex).

I have seen too many examples of software that gives up too early, mostly
because it was too expensive to program for the alternatives. I am
perfectly aware that in the end there will be a moment when all conceivable
alternatives have been tried in vain. Then the program is allowed to quit.
But not earlier. Even if a program is waiting for an Oracle database that
died and needs operator attention (don't ask me why, but it happens all the
time where I work) the program should not quit. Instead I can imagine an
OS-message to the operator, who restarts the database, after which my
program just resumes its evaluation. Same with communication lines. Even
with database hardware failures: the operator could backup on a different
machine, rerun the logged transactions and then resume my program.

My conclusion: yes we may need classical exceptions handling for a few
years to come, but that should not be the end of it. A lot more automatic
recovery support could be developed so that an applications programmer
would scarcely need to explicitly program exceptions handling.

Regards Erik Zuurbier