Try/Catch DU Exception

[Archie Cobbs]

On Sat, Jul 13, 2024 at 12:35 PM Attila Kelemen <attila.kelemen85 at gmail.com>
wrote:

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

OK let's try going down this route just for fun...  :)

Here's a sketch of how the spec might accommodate this.

For any type E extending Throwble and expression or statement X, first
define whether "X might throw E" as follows:

   - (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.
   - (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.
   - (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.
   - (Unchecked Exceptions) If E extends Error or RuntimeException, and X
   is an invocation of a method, then X might throw E.

Now consider a catch block that catches E₁ | E₂ | ...

Then the new rule would be:

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

So most of the new complexity here seems to be in dealing with all the
"special exception" cases.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240713/4550636e/attachment.htm>