Try/Catch DU Exception

[Attila Kelemen]

Adding a little bit extra on top of that: I believe that if Java ever wants
to go down this route, then it should first develop the notion of
"nothrows" (or maybe even a strong constraint on what is allowed to be
thrown), and then on top of that the flow analysis could be enhanced. I'm
not saying I'm eager for this to happen but I think that would be the bare
minimum before this issue should be considered to be fixed.

Attila Kelemen <attila.kelemen85 at gmail.com> ezt írta (időpont: 2024. júl.
13., Szo, 13:38):

> I guess the main difference in our thinking is that I value the complexity
> of the JLS more. The informal rule you are talking about (i.e., assigned
> exactly once) might appear to be simple but it is in reality impossible to
> prove completely and there is no end to complicating the formal rule. I
> mean, I showed a simple complication in my previous email already but let's
> go further. Why shouldn't the following work then?
>
> ```
> final int x;
> int i = 0;
> try {
>   x = func();
>   i++;
> } catch (Exception e) {
>   x = -1;
> }
> ```
>
> or even
>
> ```
> int end = 1;
> final int x;
> for (int i = 0; i < end; i++) {
>   x = 5;
> }
> ```
>
> All of the above would be equally possible for the compiler to deduce to
> be correct. Complicating the formal rule matters a lot for the language in
> my opinion. And of course, you could complicate the language but then I
> would expect some major gain from it. What do we gain here? That we can add
> the `final` keyword to a local variable declaration? That doesn't seem very
> valuable to me (assuming the variable capturing rule is relaxed as I wrote).
>
> Olexandr Rotan <rotanolexandr842 at gmail.com> ezt írta (időpont: 2024. júl.
> 13., Szo, 13:16):
>
>> It would be good to fix what you are saying. However, I don't agree that
>> this enhancement would introduce any new rule. Rule for final variables and
>> fields is one and only one in this context: it must be initialized once.
>> 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. Of course, JLS defines a set of rules on how to determine
>> whether the value was previously assigned or not, and, strictly speaking,
>> current behaviour is the right one. However, JLS here fails to let through
>> valid code from, lets say, a logical point of view. So, actually, no one
>> introduces new rules to the compiler. In fact, this fix would remove
>> exception from the rules that are semantically applied to final variables.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240713/a4a3bc71/attachment.htm>