Hey Osama,
On 18.6.2026 23:49:11, Osama Aldemeery wrote:
Hi all,
I'd like to gauge interest in deprecating `return` inside a `finally`
block, before I request karma to propose it as a full RFC.
A `return` inside a `finally` silently discards whatever the
`try`/`catch` was doing...a pending exception or return value just
disappears, with no error or notice.
As far as I know, it's the only abrupt exit from a `finally` PHP
leaves silent...
`break`/`continue`/`goto` out of one are already compile errors, and a
`throw` auto-chains the discarded exception as `$previous`. Only
`return` destroys the in-flight state and says nothing.
Looking into the history of `finally` I found that the author of the
original RFC said he added it only because Java allowed it, even
though he thought it made "no sense"
https://externals.io/message/61670#61678
But Java itself warns about it (`javac -Xlint:finally`).
I also found that it was the source of a few bugs:
* https://bugs.php.net/bug.php?id=70228
* https://bugs.php.net/bug.php?id=72213
* https://github.com/php/php-src/issues/11028
To see what a change would actually cost, I implemented the
deprecation
<https://github.com/php/php-src/compare/master...aldemeery:php-src:deprecate-return-in-finally>
and ran it over the top ~5000 Composer packages. And I found that it's
rare...there were only 12 occurrences across 9 packages out of 4992.
Of those, 3 look like genuine latent bugs the deprecation caught, and
the rest look deliberate.
Here's the list of the occurrences:
1. ibexa/admin-ui (swallows the exceptions its own docblock declares)
<https://github.com/ibexa/admin-ui/blob/2322d54/src/bundle/Controller/ContentTypeController.php#L834>
2. shopware/core (eats thumbnail failures and still reports success)
<https://github.com/shopware/core/blob/e8079a0/Content/Media/Thumbnail/ThumbnailService.php#L294>
3. amphp/http-server (drops exceptions when the stream is already
gone)
<https://github.com/amphp/http-server/blob/b306134/src/Driver/Http2Driver.php#L1322>
4. dvdoug/PHPCoord (deliberate...finally is the method's return)
<https://github.com/dvdoug/PHPCoord/blob/ced02c4/src/Point/CompoundPoint.php#L131>
5. dvdoug/PHPCoord (again)
<https://github.com/dvdoug/PHPCoord/blob/ced02c4/src/Point/GeocentricPoint.php#L148>
6. dvdoug/PHPCoord (again)
<https://github.com/dvdoug/PHPCoord/blob/ced02c4/src/Point/GeographicPoint.php#L221>
7. dvdoug/PHPCoord (again)
<https://github.com/dvdoug/PHPCoord/blob/ced02c4ad44aa4a558f69d53af4834a9d50ab2aa/src/Point/ProjectedPoint.php#L242-L247>
8. spatie/ray (delibrate...any failure just returns false)
<https://github.com/spatie/ray/blob/2da2079/src/Client.php#L71>
9. cakephp/cakephp (catch consumed the exception...finally just
returns array)
<https://github.com/cakephp/cakephp/blob/eef91f28de119bee5536905244d2096f752f2920/src/Database/Query.php#L1748-L1755>
10. hyperf/http-server (catch consumed the exception...finally emits
response)
<https://github.com/hyperf/http-server/blob/80c52d4/src/Server.php#L140>
11. silverstripe/framework (catch consumed the mysqli error)
<https://github.com/silverstripe/silverstripe-framework/blob/9c59c42/src/ORM/Connect/MySQLiConnector.php#L213>
12. symfony/flex (try can't actually throw)
<https://github.com/symfony/flex/blob/4a6d98e/src/PackageResolver.php#L88>
My take here is that the language already handles the analogous cases
(`continue`/`break`/`goto`/...etc) natively, so leaving `return` looks
like an inconsistency.
I lean toward deprecating it now with an eye to an error in a future
major (following the steps of Tim's deprecate-return-from-constructor
RFC
<https://wiki.php.net/rfc/deprecate-return-value-from-construct>)...though
I guess a plain warning would be fine too. The main thing is that it
seems worth doing something about.
Is there appetite for this?
Thanks,
Osama
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
