stack-bound vs. travelling closures proposal.

[Neal Gafter]

You're observing that people don't use checked exceptions much today,
and they aren't well supported (e.g. in concurrency scenarios).
That's true, but it is due in part to the shortcomings that exception
transparency aims to fix.  Your conclusion is that they don't need to
be supported because they aren't widely used, but that reasoning is
backwards: they aren't widely used in part because they aren't well
supported.  Failing to support them well means that people will be
forced to choose between avoiding checked exceptions or avoiding
higher-order programming.

On Thu, Jun 17, 2010 at 5:01 AM, Doug Lea <dl at cs.oswego.edu> wrote:
>
> 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
>
>
>
>
>
>