<div dir="ltr"><div dir="ltr">On Sat, Jul 13, 2024 at 12:35 PM Attila Kelemen <<a href="mailto:attila.kelemen85@gmail.com">attila.kelemen85@gmail.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Or... maybe there's some simpler trick that would accomplish the same thing? If so I don't immediately see it.</div></div></blockquote><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>OK let's try going down this route just for fun...  :)</div><div><br></div><div>Here's a sketch of how the spec might accommodate this.<br></div><div><div><br></div><div>For any type E extending Throwble and expression or statement X, first define whether "X might throw E" as follows:</div><div><ul><li>(Precise
 Special Exceptions) If E is assignable from one of: 
ArithmeticException, ArrayIndexOutOfBoundsException, 
ArrayStoreException, ClassCastException, AssertionError, 
ExceptionInInitializerError, MatchException, NegativeArraySizeException,
 NullPointerException, (others?) and X is one of those expressions which
 the JLS defines to possibly throw that exception, then X might throw E.</li><li>(Imprecise Special Exceptions) If E is assignable from one 
of: LinkageError (or any of its defined subclasses), 
BootstrapMethodError, StackOverflowError, InternalError, 
OutOfMemoryError, ThreadDeath (others?), then X might throw E.</li><li>(Checked
 Exceptions) If E extends neither Error nor RuntimeException, and X is 
an invocation of a method that declares it throws something assignable 
to E, then X might throw Ei.</li><li>(Unchecked Exceptions) If E extends Error or RuntimeException, and X is an 
invocation of a method, then X might throw E.</li></ul></div></div><div>Now consider a catch block that catches E₁ | E₂ | ... <br></div><br></div><div class="gmail_quote">Then the new rule would be:</div><div class="gmail_quote"><ul><li>For any variable V, then V is definitely [un]assigned at the start of the catch block iff the following is true for every Eᵢ: for every X in the try block that might throw Eᵢ, V is definitely [un]assigned before X.</li></ul></div><div class="gmail_quote">So most of the new complexity here seems to be in dealing with all the "special exception" cases.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">-Archie<br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>