Try/Catch DU Exception

[Attila Kelemen]

I personally wouldn't like too much if the compiler tried to be very smart
with this. The current behavior is very easy to reason about, and this
proposal looks too special to me. Especially because then it raises more
questions about `Thread.stop`.

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. 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.

Archie Cobbs <archie.cobbs at gmail.com> ezt írta (időpont: 2024. júl. 12., P,
22:24):

> I'd like to propose a very minor language improvement and would appreciate
> any feedback.
>
> This is a true corner case, but I bet most developers have tripped over it
> a few times. It's easy to work around... but still...
>
> Here's a simple example:
>
>     void describeMyThread(Thread thread) {
>         final String description;
>         try {
>             description = '"' + thread.getName() + "'";
>         } catch (NullPointerException e) {
>             description = "null";
>         }
>         System.out.println("the thread is " + description);
>     }
>
> This doesn't compile:
>
>     DUTest.java:8: error: variable description might already have been
> assigned
>                 description = "(null)";
>                 ^
>
> The error is a false positive: there is no way an exception can be thrown
> in the try block *after* description is assigned, because description
> being assigned is literally the last thing that occurs in the try block.
>
> Developers intuitively know that description will be DU at the start of
> the catch block, so the error feels surprising and makes the compiler seem
> less smart than it should be.
>
> My proposal is to fix this by adding a "try/catch DU exception" to
> §16.2.15:
>
> V is definitely unassigned before a catch block iff all of the following
> are true:
>     V is definitely unassigned after the try block *or the try block ends
> with an assignment expression statement V=b and V is definitely unassigned
> after b*
>     V is definitely unassigned before every return statement ...
>
> A prototype compiler implementation is here
> <https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:TryCatchDUException>
> .
>
> Thoughts?
>
> -Archie
>
> --
> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240712/de38c333/attachment-0001.htm>