(Even here there are non-universalities; what if the cleanup
wants to see the return value and/or the thrown exception?
Should it take those as one or two leading arguments?)
Probably, it's too much. Result-agnostic cleanup logic looks like the cleanest
solution from API perspective.
There are catchException and foldArguments/filterReturnValue to combine with.
Or am I missing something?
As Charlie has explained, try/finally is *just barely* doable with the existing
API points, as you note. I think we want a composite API point which can be
readily compiled down to the natural JVM operations, instead of requiring the
user to emit a complex pattern. The complex pattern will probably not be
recognizable, and so won't be compiled down to the simple JVM operations.
Don't get me wrong, I'm not against MHs.tryFinally. Quite the contrary
:-) What I talked about is result-agnostic cleanup vs result/exceptional
result passing into cleanup:
MHs.tryFinally(target, cleanup)(*a)
{ try { return target(*a); } finally { cleanup(*a); } }
vs
MHs.tryFinally(target, cleanup)(*a)
{ Either<?,Throwable> ret;
try { ret = new Left(target(*a)); }
catch(Throwable e) { ret = new Right(e); }
finally { cleanup(ret, *a); } }
My point was that additional flexibility is probably too much, since it
can be achieved using other combinators.
Best regards,
Vladimir Ivanov
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
