[e-lang] Exceptions in finally blocks (was: Shortcuts for asynchronous control flow)

[David Hopwood]

Plotnikov, Constantine A wrote:
> 4. *On exceptions from close()*. I need to think more about it for 
> Sebyla. The approach "last exception wins" is a simple and consistent, 
> but it does have the problem that you have described. However for E, the 
> behavior must match when/finally behavior in order to be consistent with 
> the rest of the language. If it is not what you like, it would be better 
> to fork out a thread about it because it is a general language issue. 
> "using" looks an utility expression over when/finally and I think that 
> it should work like it.

I agree that it should be consistent between try/finally, when/finally,
and similar user-provided control constructs.

Currently,

try {
   throw "Foo"
} finally {
   throw "Bar"
}

# problem: Bar
[...]

I think this is wrong, because it loses information. Moreover, it loses
the most useful information: IME it is almost always the first error
that is most relevant to debugging, not the last.

It should throw a nested exception encapsulating "Foo" and "Bar".


While we're at it, here is the full error message output by rune:

# problem: Bar
#
#   - Thrower#run(RuntimeException)
#   . throw("Bar")
#   @ run/1: <t:/cs/e/tryfinally.e#:span::6:8::6:8>
#   - EExpr#evalToPair(Scope)
#   . e`try {\n    throw.run("Foo"... {\n    throw.run("Bar")\n}`.evalToPair(<a Scope>)
#   @ evalToPair/1:
<jar:file:/D:/cygwin/usr/local/e/e.jar!/org/erights/e/elang/cmd/cmdMakerMaker.emaker#:span::119:57::
119:66>

# problem: Bar
#
#   - Thrower#run(RuntimeException)
#   . throw("Bar")
#   @ run/1: <t:/cs/e/tryfinally.e#:span::6:8::6:8>
#   - EExpr#evalToPair(Scope)
#   . e`try {\n    throw.run("Foo"... {\n    throw.run("Bar")\n}`.evalToPair(<a Scope>)
#   @ evalToPair/1:
<jar:file:/D:/cygwin/usr/local/e/e.jar!/org/erights/e/elang/cmd/cmdMakerMaker.emaker#:span::119:57::
119:66>
#   - static Ref#fulfillment(Object)
#   . <import:org.erights.e.elib.ref.Ref>.fulfillment(<ref broken by problem: Bar>)
#   @ fulfillment/1

This is way too verbose. It also contains internal details of the E implementation
that are just distracting.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>