[e-lang] Non-local Exits vs Defensive Consistency - Tyler Close

[Mark Miller]

---------- Forwarded message ----------
From: Tyler Close
Date: Jan 28, 2007 12:00 PM
Subject: Re: Defensive consistency and exceptions

On Sat, 2007-01-27 at 22:54 -0800, David Wagner wrote:
> It seems to me that, while exceptions do pose a challenge for defensive
> consistency, the main issue with VirtualMachineErrors is not defensive
> consistency.  VirtualMachineErrors don't pose challenges to defensive
> consistency that go beyond the challenges already present with other
> kinds of runtime exceptions.  Rather, it seems to me that the unique
> challenge that VirtualMachineErrors present is the issue of access to
> non-determinism.

The special issue with VirtualMachineErrors versus other exceptions is
that the possibility of such Errors makes it impossible to write code
that is guaranteed not to throw. For example, I can't write a private
helper function that is trusted by the containing object to do some task
without causing an exception. Just calling the helper function will
allocate another stack frame, which may be one too many, resulting in a
java.lang.StackOverflowError. VirtualMachineErrors make it too hard to
implement the object's own internal logic.

A different pattern is used for dealing with exceptions from other
objects. For example, rather than the pattern you suggested:

On Sat, 2007-01-27 at 07:13 -0800, David Wagner wrote:
> Example: When calling a method on an object in
> another trust boundary, I had been imagining that one common idiom
> might
> be something like:
>
>     try {
>         untrusted.m(...);
>     } catch (Throwable t) { ... }

The programmer will instead use an eventual sending API. For example,
the API we will soon be reviewing looks like:

    class Foo {
        private Eventual q;
        private int a;
        private int b;

        ...

        public void
        foo(final Bar untrusted) {
            final Bar untrusted_send = q.send(untrusted);

            a = ... // Update part of my state.
            untrusted_send.bar(); // eventual send to untrusted,
                                  // will not throw
            b = ... // Update more of my state.
        }
    }

Tyler