[Fwd: Re: Failure-handling as fundamental]
Mon Feb 4 19:19:02 2002
-------- Original Message --------
Subject: Re: Failure-handling as fundamental
Date: Mon, 04 Feb 2002 11:55:17 -0700 (MST)
From: Brent L Kerby <email@example.com>
Ah, this is fascinating. I'm not familiar with Prolog at all, actually,
can see that's going to have to change.
And you've just answered a problem that I hadn't mentioned yet. The
what should happen to the stack when an exception occurs? If the stack
as-is for the handler, then it will be essentially trash, because
where the exception happens, the stack may mean different things.
It sound like Prolog's solution is that the stack is restored to its
state for the handler (i.e., the state that it was in when the failing
first started), not by reverting to a copy of the stack, but by
That is, the failing statement is entirely "undone" as you said. This is
a beautiful approach. Now I that think about it, the stack is not the
that ought to be restored anyway; if the failing program had side
should have a chance to try to restore them.
I think I'm convinced that, in theory, this is the ultimate way of
failures. But, in practice, it presents the problem of implementing "undo",
which could be difficult especially if the program to be undone involves
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",
top stack item. There is no way to restore a destroyed item. UNLESS it
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,
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
- Brent Kerby