<div dir="ltr"><div>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):</div><div><br></div><div>- 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.</div><div>- 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?</div><div>- 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.</div><div><br></div><div>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).</div><div><br></div><div>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?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Olexandr Rotan <<a href="mailto:rotanolexandr842@gmail.com">rotanolexandr842@gmail.com</a>> ezt írta (időpont: 2024. júl. 15., H, 23:10):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">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. <div dir="auto"><br></div><div dir="auto">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.<div dir="auto"><br></div><div dir="auto">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.</div></div></div>
</blockquote></div></div>