Try/Catch DU Exception

[Olexandr Rotan]

I would say that even defining some "trivial stuff" is a complexity itself,
so we either should opt into analysis or opt out of it completely

On Tue, Jul 16, 2024 at 7:57 PM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> 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/726a5b04/attachment.htm>