Try/Catch DU Exception

Attila Kelemen attila.kelemen85 at gmail.com
Tue Jul 16 17:34:57 UTC 2024


>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240716/cc4a6655/attachment.htm>


More information about the amber-dev mailing list