Try/Catch DU Exception

[Attila Kelemen]

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

Maybe somewhat more invasive to the spec but I don't think it would be the
place you are referring to. So, if the spec had the concept of "nothrows"
(i.e., when an expression / statement cannot throw an exception), then you
"just" needed to change the flow analysis. It would not need "DU for the
purpose of the catch". I didn't try to formalize it but I don't see it more
complicated than a break / continue of a loop. At least in this case I
would be mostly neutral about the change because it would be
conceptually more compact.

My problem with this special case is that it is rather arbitrary to just
rule that this is important and others are not, and if things get "fixed"
on a case by case basis, then I worry that the language rule will
effectively evolve into: "Let's type it in, and see if the compiler is ok
with it". Which pretty much the case for generic type inference, and that
doesn't have a good track record for being bug free. In fact, I remember
reporting one bug in it on the javac list, and the response I got was
basically that "we are aware but it is too complicated to fix" (and I can
empathize with that). I would avoid going down the route of special rules
for something like this. Especially since it is actually rare (though
annoying of course), and the workaround is mostly trivial (you can factor
that out into a method).


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

I guess given Tagir's comment that `Thread.stop` is not a thing now, it is
a non-issue. But if it still worked, then the question you would be asking
is: "Can an exception be raised after the last statement but before the end
of the `try` block?". To be honest I was never sure if that was possible or
not, and I hated to think about the possibility of `Thread.stop` until I
just accepted that I won't because it is practically impossible to write a
code that is guaranteed to remain consistent after an asynchronous
exception.


> 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 :)
>

I'm not sure what counts as official but I would much certainly welcome
such a change. I have always found it silly that you can't capture a local
variable just because it took multiple steps to initialize.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240713/4c634b15/attachment.htm>