Try/Catch DU Exception

[Attila Kelemen]

>
> 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.
>
> Thinking a little more about this, I think the selection of the exception
should be somewhat different. There are of course the exceptions that the
JLS defines to be a possibility (e.g.,  `ArrayIndexOutOfBoundsException`),
those would be good to be tracked. However, otherwise I think going down to
the level of `LinkageError`, `BootstrapMethodError`, etc.is a bit too much.
I think it probably would be enough to say in those cases that `Error` or
any of its subclasses.

Also, I don't see the point of distinguishing between checked and unchecked
exceptions. Because technically it is possible for a method to throw any
exception. So, as for method calls I would just say that a method call may
throw any exception (maybe special casing autoboxing and string
concatenation), and ignoring that possibility would be rather dangerous
(especially for the DA case).

Out of scope: I probably would find it better to have an independent part
of the spec defining a "flow graph" for the code where this "flow graph"
would be a directed graph where nodes are the atomic statements /
expressions and there would be an edge (A -> B) between two nodes, iff B
might be a statement / expression after A. Of course, an edge doesn't
necessarily have to mean real possibility. And then the spec could refer
back to this graph. For example, I think it would be easier for this (at
least it would be easier from the formalization point of view). Also, if
the edges would be labeled with something like "subscope", "exit scope" or
something like these, then maybe it would even be reusable for the scope of
pattern variables (though I haven't thought much about this).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240714/a19ca84a/attachment.htm>