[Fwd: Re: Failure-handling as fundamental]

[Mario Blazevic]

-------- Original Message --------
Subject: Re: Failure-handling as fundamental
Date: Mon, 04 Feb 2002 11:55:17 -0700 (MST)
From: Brent L Kerby <bkerby@email.byu.edu>
To: blamario@yahoo.com

Ah, this is fascinating. I'm not familiar with Prolog at all, actually, 
but I
can see that's going to have to change.

And you've just answered a problem that I hadn't mentioned yet. The 
problem is:
what should happen to the stack when an exception occurs? If the stack 
is left
as-is for the handler, then it will be essentially trash, because 
depending on
where the exception happens, the stack may mean different things.

It sound like Prolog's solution is that the stack is restored to its 
original
state for the handler (i.e., the state that it was in when the failing 
statement
first started), not by reverting to a copy of the stack, but by 
backtracking.
That is, the failing statement is entirely "undone" as you said. This is 
truely
a beautiful approach. Now I that think about it, the stack is not the 
only thing
that ought to be restored anyway; if the failing program had side 
effects, it
should have a chance to try to restore them.

I think I'm convinced that, in theory, this is the ultimate way of 
dealing with
failures. But, in practice, it presents the problem of implementing "undo",
which could be difficult especially if the program to be undone involves 
loops,
which could make impossible to trace back the execution.

Actually, there are many cases in which information is literally destroyed,
making "undo" impossible ... for example, an execution of "drop", 
destroying the
top stack item. There is no way to restore a destroyed item. UNLESS it 
was not
really destroyed, but just snuck away somewhere for the purpose of assisting
"undo" later should it be necessary.

Another practical concern I see is that a failing program has no way here to
pass on information about what caused the error. Traditionally, (at least in
Java) when a failure occurs, a parameter (an Exception) is passed up, 
explaining
the failure. Is there a neat way for that to fit into the system?

This is a lot to think about. I'm going to have to go do some Prolog 
reading ...

- Brent Kerby