On Fri, Jun 10, 2011 at 7:11 PM, Charles Oliver Nutter
<head...@headius.com> wrote:
> 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.
...
> 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?
I think I have it, and maybe I am wrong after all!
MethodHandle result = MethodHandles.catchException(foo,
Throwable.class, postException);
result = MethodHandles.foldArguments(postCall, result);
This case will only call postException if there's a Throwable thrown.
Because this is for a finally block, postException should re-throw the
error, which will bypass logic in postCall. If there's no exception,
postCall gets the folded return value and proceeds as normal.
If postException does *not* re-throw the error, then it's not a
finally clause; it's a catch clause, which *should* then run the
postCall result too.
Any flaws in my logic? If not, then...WHEW.
This definitely needs to go in the cookbook.
- Charlie
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to jvm-languages@googlegroups.com.
To unsubscribe from this group, send email to
jvm-languages+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
