Try/Catch DU Exception

[Maurizio Cimadamore]

Hi,
I've been following this thread from afar. To be honest, the cost in 
terms of spec complexity don't seem to be worth the increased 
expressiveness.

(A) seems simple enough, but I tend to agree that it does look a bit 
ad-hoc, and will break when more complex control flow is involved.

With (C) and (D) we seem to hit diminishing returns quickly (do we 
really want to know which assignments are or aren't possible given the 
type of exception thrown by statement and the catch we're in - seems 
overkill).

(B) seems the best compromise, in the sense that at least there's only a 
predicate on statement. But DA/DU is already a complex beast as it is, 
and I just don't see enough of a justification to "fix" this. Of course 
this subjective.

Maurizio

On 16/07/2024 18:57, Archie Cobbs wrote:
> OK so just to summarize the various options...
>
> A. "Last assignment" - the original simple fix that only applies when 
> the last statement is an assignment statement
> B. "Simple throws" - classify all statements in two buckets "can 
> throw" and "cannot throw"; assume any "can throw" statement can throw 
> anything type of exception
> C. "Complex throws, any checked" - classify all statements by which 
> exception types they can throw; assume methods can throw any unchecked 
> or checked exceptions
> D. "Complex throws, declared checked" - classify all statements by 
> which exception types they can throw; assume methods can throw any 
> unchecked or declared checked exceptions
>
> And of course "do nothing" is always the default option :)
>
> I'd also like to hear other folks' opinions.
>
> -Archie
>
> On Tue, Jul 16, 2024 at 12:35 PM Attila Kelemen 
> <attila.kelemen85 at gmail.com> wrote:
>
>         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.
>
>
>     If it is worth it or not of course is a question of preference. To
>     my mind, it is much cleaner than the special rule for "last
>     statement is assignment". I think the only way to decide if it is
>     worth it or not is if many more people would voice their opinion.
>     To me it just feels too special to talk about the "last
>     assignment" and what is that last statement.
>
>     To me actually the most strange property of the "last assignment"
>     rule is that an "if-else" chain would not work. Not so much that I
>     want to make one more trivial assignment. But I think if the rule
>     wants to allow the "if-else" chain then it is probably easier to
>     allow your last example as well.
>
>     As for the exceptions: There can be other middle grounds here to
>     simplify stuff. I originally thought that a statement or
>     expression can either throw an exception or not, and if it can, we
>     assume that it may throw literally anything (so, `x = a.b;` is
>     assumed to potentially throw an `IOException`). That would make
>     the rules a lot simpler, yet would be still less surprising in my
>     opinion.
>
>
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240717/976c74ea/attachment.htm>