(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); } }


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

Reply via email to