<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 class="gmail_quote"><div><div>For any type E extending Throwble and expression or statement X, first define whether "X might throw E" as follows:<br></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></div></blockquote><div>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`, <a href="http://etc.is">etc.is</a> a bit too much. I think it probably would be enough to say in those cases that `Error` or any of its subclasses.</div><div><br></div><div>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).</div><div><br></div><div>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).</div></div></div>