Exception transparency - lone throws (no checked exceptions)

[Reinier Zwitserloot]

transparency as in the ability to let the boundaries of the closure not
affect the meaning or runtime execution of break, continue, and return
statements, often referred to as "long" return/break/continue.

I have no idea what the Neal Gafter Dictionary says. Perhaps you can send me
a copy.

Your declaration that undermining compile-time exception checking is a
non-starter is somewhat odd in two different ways:

1) Why is that a non-starter, exactly? Would it help if I claimed that the
apparent amount of syntax required (whatever it ends up looking like) to
support explicit exception transparency is a non-starter? Now we have two
claims of non-starter-ness.

2) It doesn't undermine compile-time exception checking. Perhaps you do not
understand the proposal. Simplifying considerably, the proposal is built
around the notion that *IF* the lexical scope matches the runtime stack
(that is, the location of a closure in the source file actually matches a
stack frame that's guaranteed to still be on the stack anytime the closure
is executed), then one can treat checked exceptions thrown in closures no
different form how a for loop would handle them - i.e., not at all. They
fall through all by themselves, checked exception constraints are preserved.
It offers no solution whatsoever for when this principle (lexical scope
matches runtime stack) does not hold, other than the observation that
exception transparency isn't usually a requirement when that happens. The
proposal also does not exclude other exception transparency solutions to
handle such cases. Exactly how does treating closures that work like, say, a
for loop's body does, as inherently exception transparent undermine
compile-time exception checking? Lots of use-cases where explicit exception
checking seems to be the right answer won't actually work that way. See the
part about how "throws E" seems impossible to retrofit onto e.g. a TreeSet's
Comparator instance in the post to this mailing list introducing the
concept. If truly you believe full exception transparency done in a way that
supports all these use cases is required (I don't think you do, but then I'm
a bit confused as to where you've drawn the lines), then there is no closure
proposal that's anywhere near acceptable and I don't see how one could
create such a thing without breaking backwards compatibility.

--Reinier Zwitserloot



On Wed, Jun 16, 2010 at 11:10 PM, Neal Gafter <neal at gafter.com> wrote:

> On Wed, Jun 16, 2010 at 10:03 AM, Reinier Zwitserloot
> <reinier at zwitserloot.com> wrote:
> => Neal, I've admitted that the syntax-based exception transparency plan no
> > doubt handles the most use cases of the 3 solutions offered (explicit,
> > implicit-for-impure, lone throws) However, I've also said that the
> frequency
> > of cases that it can handle that my pure/impure concept can't is most
> likely
> > rather small, whereas the extra complexity required is enormous, and not
> > just for the compiler builders - generics is still a source of
> never-ending
> > puzzlers.
>
> It's not merely a matter of not handling the cases, notwithstanding
> the inaccuracy of your guesses about their frequency.  Undermining
> compile-time exception checking is a nonstarter.
>
> > In the case of generics I don't know of any proposal that gave us
> > most of the power without most of the complexity, but if it HAD come
> along
> > it might well have been the better choice. There was no such proposal,
> the
> > considerable added complexity was nevertheless worth doing because the
> added
> > expressiveness outpaced the complexity.
>
> The alternative was called declaration-site variance, but because it
> would not have allowed the existing collection classes to be
> retrofitted it was rejected as an option.
>
> > Incidentally, pure/impure closures make adding return/break/continue
> > transparency very simple; all that needs to be done then is invent new
> > syntax to be able to specify the target of a return statement, somehow,
> > either by letting you explicitly target them e.g. with labels like you
> can
> > with breaks/continues, or by inventing a new syntax for local return.
>
> This paragraph doesn't make sense.  I suspect you don't know what
> "transparency" means in the context in which you are attempting to use
> it.
>