Try/Catch DU Exception

[Archie Cobbs]

Thanks for the feedback. Following up...

The current behavior is very easy to reason about, and this proposal looks
> too special to me.... I guess the main difference in our thinking is that I
> value the complexity of the JLS more.


Yes, this definitely falls into the category of "tactical fix". It's a
specific (small) fix for a specific (small) corner case.

You raise a good question re: whether we should be looking at a bigger
picture, for example your if/then/else example. That would mean replacing
"last statement of the block is V=x" with something more general.

My concern is that extending this idea in that way would necessarily be
much more invasive to the spec. Instead of defining and tracking two things
(DA and DU) for every possible expression, the JLS would now have to track
three things: DA, DU, and "DU for the purpose of catch". Chapter 16 would
expand by 50%.

So this changes the cost/benefit equation by a lot.

Or... maybe there's some simpler trick that would accomplish the same
thing? If so I don't immediately see it.

Especially because then it raises more questions about `Thread.stop`.


Like what? In the source code, the catch block still can't *use* the
variable, because it's still not DA. All that's changed is that it can now
*assign* the variable.

Also, the way this issue is presented is not much of a concern (at least
> for the example code). Not making the local variable final is kinda
> whatever.


That's a personal preference thing. For me making variables final is
important for improving code readability and I do it literally whenever
possible.


> Where this is annoying is when you want to capture the variable (mostly in
> a lambda). However, if that is the issue that you are trying to address,
> then I think this is the wrong solution to that issue. I think the real
> solution to the issue would be relaxing the constraint to be able to
> capture a local variable: We should be able to capture it, iff the variable
> is definitely assigned before capturing, and there is definitely no
> assignment after it.


That's *not* the issue I'm trying to address, but I totally agree with you
that it would also be a good one to have. Are you officially proposing it?
If so, I support you :)

Would not that be addressed with the suggested switch-case-throws? See
> https://inside.java/2023/12/15/switch-case-effect/
>

That's a workaround, yes, but not a fix.

This fix would just make enforcement of this rule more precise by modifying
> existing compiler rules that currently don't let through code that is
> intuitively and factually correct, but falls into a blind spot of
> specifications. ... [separate email] ... I mean, I showed a simple
> complication in my previous email already but let's go further. Why
> shouldn't the following work then?


So to summarize what I think we can all agree on:

   - In an ideal world, the compiler would perfectly/precisely identify any
   situation where a final variable was not assigned exactly once.
   - Due to the halting problem we know this is impossible. The best the
   JLS can do is define a reasonable approximation, and everyone understands
   that the rules are just an approximation.
   - What we have does a pretty good job but it's not perfect. It will
   never be perfect.

Life is full of such situations :) In these situations we typically make
incremental improvements over time, pragmatically, on a cost/benefit basis.

So to me the question is not "What are the *correct* rules for DA/DU" - no
such rules exist - but where are there opportunities to do the normal
incremental improvement thing where the cost/benefit ratio is favorable.

For this proposal, it's a one line JLS change. Like I said, a small fix for
a small corner case.

I'd also support the more general version, as long as I don't have to be
the one who updates Chapter 16 :)

I also think replacing the "effectively final" requirement for lambdas &
inner classes to be "DA at the point of instantiation and not reassigned
afterward" would be another good one, but that's a separate proposal...

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240713/d660ee12/attachment-0001.htm>