Try/Catch DU Exception

Archie Cobbs archie.cobbs at gmail.com
Tue Jul 16 16:57:31 UTC 2024


On Tue, Jul 16, 2024 at 10:32 AM Attila Kelemen <attila.kelemen85 at gmail.com>
wrote:

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

I agree with you that relying on properly checked exceptions opens up a new
kind of hole that didn't exist before. In other words, in the places that
it doesn't perfectly match reality, the current DA logic always errs on the
side of caution, but if it started relying on properly checked exceptions
that would mean doing the opposite, even though (arguably) it has the
"right" to do so.

OK so for the sake of argument let's take your position and suppose we
don't want to do that. Then every method call becomes a possible branch to
the catch clause (regardless of what is caught). In addition, you still
have all the special cases like NegativeArraySizeException, and you have
Error being thrown anywhere.

So now basically everything except "trivial stuff" like plain arithmetic
must be assumed to possibly throw some kind of exception. And all this buys
beyond the original simpler proposal is that the compiler now knows that
"trailing trivial stuff" can't throw an exception. For example:

final int x;
int neg_x = 0;
try {
    x = method();
    neg_x = -x;       // "trailing trivial stuff"
} catch (Exception e) {
    x = 0;
}

At this point, is it even worth it to do this more complicated analysis?
It's not much gain for all that work when compared to the original simpler
fix.

-Archie

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


More information about the amber-dev mailing list