On Fri, Jun 10, 2011 at 7:04 PM, Charles Oliver Nutter
<[email protected]> wrote:
> Brainstorming ways this could be fixed in JSR-292, if it's not already
> impossible to do so.
>
> 1. A new MethodHandles API postProcess, that receives all incoming
> arguments, invokes the handle, and runs a post-processor on the
> arguments plus the result of the handle
Ok, John Rose pointed out on MLVM list that a finally that does not
return would be the same as foldArguments, by flipping the order:
int foo(Object arg1) {
... return some int
}
int postCall(int retVal, Object arg1) {
post(arg1);
return retVal;
}
MethodHandle result = MethodHandles.foldArguments(postCall, foo);
foo's return value then gets inserted into postCall's param list, and
you can either use it or not. Clever...I didn't think to reverse the
order of foldArguments.
But unfortunately:
> MethodHandles foo = <get foo() handle>
> MethodHandles postCall = <get postCall() handle>
> MethodHandles postException = <get postException() handle>
>
> MethodHandle result = MethodHandles.postProcess(foo, postCall)
> result = MethodHandles.catchException(result, Throwable.class, postException);
>
> This is *pretty close* to real finally logic; the flaw in this design
> is that exceptions from postCall will *also* end up in postException.
This problem still applies. If I instead use John's pattern and do:
MethodHandle result = MethodHandles.foldArguments(postCall, foo);
result = MethodHandles.catchException(result, Throwable.class, postException);
The postCall logic could raise an exception that postException is not
meant to handle. Am I wrong?
- Charlie
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
