Try/Catch DU Exception

[Olexandr Rotan]

Well, that's valid. However, kotlin design choice to step off from JLS in
checked exceptions handling (their absence, more specifically) has its
consequences, both positive and negative, and potential incompatibilities
with java code in what requirements compiler imposes to final variables in
context of try/catch block is one of those.

While, as I said previously, we have to respect other JVM languages, if
they want both bytecode compatibility with Java and step off from JLS at
the same time, it has its cost. We should not break this compatibility
wherever, no matter what the price is, just because we can, but if decision
to change JLS brings significant value to Java itself, we certainly should
do it, and it's other language teams work to bear with outcome of their
decisions.

While we certainly should write this issue in "cons" column, I would not
mark it as crucial as long as it does not break compatibility of Java
bytecode with itself. It's J in the JDK after all.

On Mon, Jul 15, 2024, 21:52 Attila Kelemen <attila.kelemen85 at gmail.com>
wrote:

> Olexandr Rotan <rotanolexandr842 at gmail.com> ezt írta (időpont: 2024. júl.
> 15., H, 20:49):
>
>> Specifically in that case, I wouldn't say that this is kind of an issue
>> that is significant enough to discard the idea, it is still a con of this
>> change, and, imo, must be accounted. Though for kotlin specifically, there
>> are much greater compromises that kotlin devs are used to than final
>> variable that may be accidentally initialized twice
>>
> Actually the main concern here is not that a variable is initialized twice
> (that would be whatever in my opinion). The main issue is that you might be
> able to observe a value of a variable that should be impossible.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240716/b60bdb3d/attachment.htm>