Neal Gafter wrote:
> I like this. The exception tables presumably would be allowed to contain 
> entries for subtypes of Jump.

And if possible, optimized to only be interested in jumps generated 
immediately within the interesting scope, to filter out jumps generated 
at deeper scopes not directly of interest.

/** runs the given closure five times for each element */
public void fiveForEach(Closure c) {
   int elementIndex = 0;

   while (elementIndex < size) {
     int loopCount = 0;

     loop { // loop takes a closure
       if (loopCount >= 5) break; // return ends the inner loop

       c.call(getElement(elementIndex));
       loopCount++;
     }
     elementCount++;
   }
}
...
public Object weirdFind() {
   x = createSomeList();
   x.fiveForEach {(Object o) if (someTest(o)) return o; }
}

Here, the run method is only interested in a ReturnJump, and more 
specifically, it's only interested in the ReturnJump that would be 
generated within the closure passed to fiveForEach. The loop inside 
fiveForEach is only interested in the BreakJump generated inside the 
loop. However, because the ReturnJump is generated by a call to that 
closure inside the loop, it will pass through the loop's 
jump/exception-handling table. Rather than have all closure-accepting 
methods catch and filter all jumps, it would be preferable that they 
only catch the ones they could reasonably respond to.

Of course, it should still be possible for someone to write code that 
explicitly catches Jump, to avoid a rogue (i.e. badly compiled?) jump 
event from blowing the whole stack. This could also be a recommended 
documentation practice:

will capture any return or break jumps passing through it:
/**
  * ...
  * @jumps ReturnJump, BreakJump
  */

...

will capture all jumps; don't expect jumps passing through this to escape
/**
  * ...
  * @jumps *

Unnecessary perhaps?

- 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to