On Sat, Jun 20, 2026 at 4:25 PM Bob Weinand <bobwei9@hotmail.com> wrote:
> I dislike this.
>
> Yes, it's a rare occurence. But it's used legitimately in most places you
found. (as you say, only 3 places were genuine issues.)
>
>
> So, why do you want to remove this? What's the point? It has some proper
usage sites.
>
> We do have well-defined behaviour for return in finally. It works
properly (by now) - it's not like it's a frequent source of bugs - there
were a couple ones when initially introduced 10+ years ago, and a single
one more recent.
>
>
> Also, no, it's not inconsistent - goto, continue etc. break out of the
finally block and continue the functions execution. A return stops function
execution as well. These are two different considerations.
>
>
> Feels a lot like "let's try changing something for the sake of it". No
thanks.
>
>
> Thanks,
> Bob
Hi Bob,
First, on framing, even though what I am suggesting here is removing it, I
deliberately left the door open to a plain warning if people here
preferred. The thing is that this is a silent footgun worth addressing...
So I'll admit I didn't expect "leave it entirely" to be on the table for
something that discards the in-flight state silently.
On the "why" itself, it's not that the behavior is broken, it works exactly
as defined. The problem is what it's defined to do, a return in finally
silently discards a pending exception or return value, with no diagnostic
at all. That *silence* is the whole case. And it's where the real damage is.
The genuine cases I found are exactly that...a controller that swallows the
very exceptions its own docblock declares it throws, a service that reports
success after an I/O failure, and an HTTP driver that drops exceptions when
a stream is gone. Nothing surfaces any of it, which is why they ship and
stay shipped.
So the benefit here is that we close a tiny gap that makes behavior less
surprising and more predictable, and the cost of addressing that is close
to nothing. It's in 0.18% of the top 5000 packages, and the deliberate uses
don't even need it, the same behavior can be achieved in other ways
(sometimes just one line away...the return just past the finally). So it
removes no capability, it just makes the silent cases visible.
On consistency, you're right...the jump bans are different. But that
doesn't remove the concrete issue = the silent discard. That stays
unchanged.
Thanks,
Osama
