stack-bound vs. travelling closures proposal.

[Neal Gafter]

On Wed, Jun 16, 2010 at 9:18 PM, Reinier Zwitserloot
<reinier at zwitserloot.com> wrote:
> There's only one caveat: The author of the Collections.sort method may
> presume that any call to Comparator.compare() couldn't possibly throw, say,
> an IOException, because "compare()" does not declare this. And that would be
> a mistake - this entire concept is predicated on the notion that any checked
> exception not explicitly declared by that closure falls "through" all
> intermediate methods right back to the original lexical scope, at which
> point it'll be handled. This fall-through scheme can only work if none of
> the intermediate methods catch the exception.

It is legal for an invocation of the comparator to be contained within
a try block for which there is a catch block for IOException, as the
language specification enumerates precisely those positions within the
try block from which an IOException can occur.  If the comparator is
not one of those positions, then an IOException must not be propogated
out from an invocation of the comparator or the invariants of the
language are undermined.