stack-bound vs. travelling closures proposal.

[Doug Lea]

I haven't been following this discussion very closely, but
I think something along the lines of this proposal seems
plausible.

Backing up a little, three observations:

1. In practice, the majority of checked exceptions most
developers use/see are IOExceptions.

2. Code doing IO is not very amenable to "lightweight"
closure processing, either in sequentially or in parallel.
(You need heavier OS support to cope with blocked IO etc.)
We effectively ban IO in ForkJoin framework by ...
not allowing actions to throw checked exceptions!
This is a little annoying for those people who either
use non-IO-based checked exceptions, or use well-behaved
cancellable etc IO. But no one has ever complained to us
about needing to occasionally tunnel or escalate.
(Aside:  More generally, closures are all about "lightweight".
When code requires a lot of state or helper methods etc.,
people define classes; they don't pass around closures.
Even though they of course could. Closures and Objects
are isomorphic at some level).

3. In most programs using ForkJoin, Futures, Callables etc.,
exact task/function types quickly wash out, so people
end up writing many full generic generic declarations
that would not be commonly inferable even with better
type inference. So if exception params are added,
many people will need to type the whole ugly version
most of the time, and will not be happy about it.

This all leads me to think that the main focus for
language support should be for usages without checked
exceptions, with at best limited support for checked forms.
Reinier's proposal seems to be one of a few plausible
approaches to this.

-Doug