Proposal: `finally` block exception suppression

[Kamil Ševeček]

Personally, I think finally should have the suggested semantics with
suppressedException. On the other hand, I understand that this would change
the behavior of an existing language construct, which has no previous
precedent.
I would argue for a similar path to switch/case when avoiding fall through.
Could you not come up with an alternative syntax that is as intiutive as
the original try ... finally, but has new semantics?

Kind regards
Kamil Sevecek

On Sun, 17 Jul 2022 at 14:11, <
some-java-user-99206970363698485155 at vodafonemail.de> wrote:

> > Besides the compatibility concerns of changing the operational semantics
> > of code that has been written for year or even decades
>
> There might be a risk of compatibility issues, but I think it is rather
> low. As outlined in my proposal
> it would mostly affect applications which inspect the suppressed
> exceptions in some way.
> I can definitely understand your concerns regarding compatibility, but I
> am also a bit afraid that
> this whole proposal is rejected due to theoretical issues which might
> never occur in practice.
>
> > should judge how often suppressedExceptions are looked at today. JDK 7
> with try-with-resources
> > shipped in July 2011 so there has been ample time for developers to take
> advantage of the
> > suppressed exceptions information
>
> That is probably difficult to measure, but this would also then turn this
> whole discussion into
> a discussion about whether suppressed exceptions as a whole are useful.
>
> I have done a quick search and found the following blog posts / websites
> describing this issue.
> Some have been written before the introduction of try-with-resources, but
> as outlined in the
> proposal, it is not possible to use try-with-resources in all situations.
> - https://stackoverflow.com/q/25751709
> - https://stackoverflow.com/q/3779285
> - https://stackoverflow.com/q/59360652
> -
> https://www.linuxtopia.org/online_books/programming_books/thinking_in_java/TIJ311_014.htm
> - https://accu.org/journals/overload/12/62/barrettpowell_236/
> - https://errorprone.info/bugpattern/Finally
> -
> https://wiki.sei.cmu.edu/confluence/display/java/ERR05-J.+Do+not+let+checked+exceptions+escape+from+a+finally+block
>
> In addition to these  there are the OpenJDK bug reports I mentioned in the
> proposal:
> - JDK-4988583: which is the same as this proposal
> - JDK-7172206: bug which is caused by this flaw and still exists today (if
> I see that correctly)
>
> One could now argue that this issue has been so widely discussed that
> developers
> should by now all be aware of this issue and avoid it. But I think it is
> quite the opposite:
> The current behavior is flawed and developers (who might even be aware of
> this issue)
> keep running into this issue and therefore try to warn each other about
> it. And any
> solutions or workarounds to this are pretty verbose and quite error-prone.
>
> Of course it would have been ideal if suppressed exceptions existed from
> the beginning
> and the `finally` block behaved like try-with-resources statements with
> regards to exception
> suppression. But I think with the current situation it would at least be
> good to improve it in
> the best way possible.
>
> If you and the other OpenJDK members think that this proposal is
> definitely not going to be
> included (or also independently from this decision), what do you think
> about reviving JDK-5108147?
> This would at least make manual exception suppression in `finally` blocks
> easier:
> ```
> try {
>     someAction();
> }
> finally (Throwable t) {
>     try {
>         cleanUp();
>     }
>     catch (Throwable t2) {
>         if (t == null) {
>             throw t2;
>         } else {
>             t.addSuppressed(t2);
>         }
>     }
> }
> ```
>
> Kind regards
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20220809/1a9a50f3/attachment.htm>