Try/Catch DU Exception

[Attila Kelemen]

Other languages (like Kotlin) are just examples of how it can happen the
easiest. Let me explain the problem then this way (and let's ignore the
more practical concerns I have raised previously):

- The JLS is a big mathematical architecture, and as such has an
Achilles heel: Contradiction. If there is even a single one, then
everything collapses immediately.
- When people wrote some sections of the JLS, there is a great
likelihood that they had the assumption in their head that a variable is
always assigned. For local variables, this is ensured via the "definitely
assigned" property. Can you confidently say that breaking such a
fundamental assumption will not cause a contradiction anywhere else in the
JLS?
- One option you could think of is that the JLS will now just state that if
a method not declaring a checked exception throws one anyway, then that is
an undefined behavior. However, if you look at the JLS, then the JLS sets a
very high bar for doing so. And even then it still severely limits the
possibilities.

So, the problem is that the JLS cannot ignore the possibilities the JVM
allows, because the JVM basically defines the laws of physics for it. If it
did ignore it, then javac would be in big trouble. And not even Mourinho
would want that :). That is, if the JLS states that "X" must happen, then
it is never acceptable that when you run the code something else happens.
Whatever you write into the JLS for this feature must cover all
possibilities that might happen in the JVM (worst case by stating that
doing something is an undefined behavior).

Now look at the gain we might have: We could differentiate between checked
and unchecked exceptions for the purpose of better flow analysis. I'm not
saying it is nothing but is it really worth the risk of blowing up the JLS?

Olexandr Rotan <rotanolexandr842 at gmail.com> ezt írta (időpont: 2024. júl.
15., H, 23:10):

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240716/299a00f5/attachment-0001.htm>