Exception transparency - lone throws (no checked exceptions)

[Jesse Kuhnert]

Can't someone just kick ban him? I mean really.. If he were standing
in front of me I think I'd probably be tempted to hit him.

On Wed, Jun 16, 2010 at 6:36 PM, Reinier Zwitserloot
<reinier at zwitserloot.com> wrote:
> 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.
>>
>
>