[e-lang] Notes from latest Joe-E meeting

[Tyler Close]

Hi David,

The goal for the Error handling is to ensure that Joe-E code cannot
cause any side-effects after an Error is thrown. So far, we've got two
hypothetical ways of handling this: ensure that the next method call
after a thrown Error is a call to JoeE.abort(), which does a
System.exit(); or prevent Joe-E code from either catching the Error,
or executing any finally clause, in which case the Error bubbles up to
the first stack frame.

On 4/29/07, David Hopwood <david.hopwood at industrial-designers.co.uk> wrote:
> [repost after changing address; sorry if this is a duplicate]
>
> Tyler Close wrote:
> > On 4/26/07, Mark Miller <erights at gmail.com> wrote:
> >
> >>- There is an attack with try-finally and VirtualMachineError.
> >>     try {
> >>        ... X ...
> >>     } catch (final Error reason) {
> >>       throw JoeE.abort(reason);
> >>     } finally {
> >>        ... Y ...
> >>     }
> >
> > We could change the boilerplate for a finally clause to:
> >
> >     try {
> >         ...
> >     } catch (final Error e) {
> >         while (true) { try { JoeE.abort(e); break; } catch (Throwable t) {} }
> >         throw e;
> >     } finally {
> >         ...
> >     }
>
> That doesn't work. A VirtualMachineError can still be thrown during the
> 'while (true) ... throw e;' block, and not caught by the 'catch (Throwable t)'.

The JLS pretty much says all bets are off after an Error is thrown, so
I don't think we'll be able to find anything that is correct by
definition. For now, we're just trying to find something that is
correct in practice. Do you know of any JVM that will break out of the
above while(true) loop without calling JoeE.abort()?

> > Another possibility:
> >
> >     Error abort = null;
> >     try {
> >         ... anything but assignment to abort ...
> >     } catch (final Error e) {
> >         abort = e;
> >     } finally {
> >         if (null != abort) { throw abort; }
>           ...
> >     }
>
> [I've added '...' where user code would go.]
>
> This still does not guarantee the required semantics -- what if a
> VirtualMachineError occurs just before 'abort = e;'?

Same argument as above.

> Remember, VirtualMachineErrors are *entirely* nondeterministic and can happen
> at any time (at least as far as the Java spec is concerned, and we don't really
> want to rely on properties of specific Java implementations). They do not
> necessarily only occur at uses of 'new' or method calls.

I agree we really don't want to, but they've not left us with much
alternative. If we don't find a hack that works in practice, we'll
have to ban catching of Error *and* finally clauses. As a test, I've
rewritten all my code to not use finally blocks, so it is doable, but
it might make Joe-E a harder sell.

Tyler

-- 
The web-calculus is the union of REST and capability-based security:
http://www.waterken.com/dev/Web/

Name your trusted sites to distinguish them from phishing sites.
https://addons.mozilla.org/firefox/957/