Try/Catch DU Exception

[Archie Cobbs]

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/20240716/14e8e252/attachment-0001.htm>