Doc #74569 [Com]: Return in a finally clause silently ignores an exception thrown in a try clause
| From: | anhlephuoc at gmail dot com | Date: | Sun, 22 Nov 2020 19:16:12 +0000 |
| Subject: | Doc #74569 [Com]: Return in a finally clause silently ignores an exception thrown in a try clause | ||
| References: | 1 | Groups: | php.doc.bugs |
| Request: | Send a blank email to doc-bugs+get-18146@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=74569&edit=1
ID: 74569
Comment by: anhlephuoc at gmail dot com
Reported by: trianman at gmail dot com
Summary: Return in a finally clause silently ignores an
exception thrown in a try clause
Status: Open
Type: Documentation Problem
Package: Scripting Engine problem
Operating System: Any
PHP Version: 7.1.4
Block user comment: N
Private report: N
New Comment:
This faulty behaviour of the return statement in the finally{} of the the try{} block extends beyond
the catchable error/exceptions.
1%0; // No warning or error.
unknown_function(); // not reported. Program not aborted
It took me days to locate a misspelled function, because no error is reported at all and program
would normally abort, now continue with undesirable behaviour.
Example code:
<?php
error_reporting(E_ALL|E_STRICT);
function do_test(): int {
try {
1/0; // a warning in php 7 - reported as documented
nonexistent_function(); // a fatal error - not reported - program continues
1%0; // a fatal error
return 0;
} catch (Exception $e) {
printf("CATCH\n");
return 1;
} finally {
printf("FINALLY\n");
return 2;
}
return 3;
}
printf("%d\n", do_test());
Previous Comments:
------------------------------------------------------------------------
[2017-05-16 21:16:02] danack@php.net
The Php Inspections (EA Extended) guy has added this as code smell to that tool.
You could consider using that tool and giving them some money for being so nice: https://www.indiegogo.com/projects/php-inspections-ea-extended-a-code-analyzer-security#/
------------------------------------------------------------------------
[2017-05-14 19:09:19] cmb@php.net
It seems to me this is simply a documentation issue.
------------------------------------------------------------------------
[2017-05-12 18:24:10] trianman at gmail dot com
2 danack@php.net
Sorry, I don't want to be mean. My English skills are not very good and it is sometimes hard to
express my thoughts in a clear way.
I've just realized that the finally statement is some-kind of antipattern for me. Because
finally is a shortcut for catching and re-throwing an \Exception class eg.
<?php
try {
throw new CustomException();
} catch (CustomException $ex) {
handleException();
} catch (\Exception $ex) {
doThingsInFinally();
throw $ex;
}
doThingsInFinally();
?>
Or with finally:
<?php
try {
throw new CustomException();
} catch (CustomException $ex) {
handleException();
} finally {
doThingsInFinally();
}
?>
Of cause if we have a return statement instead of a doTihingsInFinally() method, we will lose an
exception. But we doing it in a clear way. On the other hand finally statement hides out from
developer's eyes what actually is going.
So for my mind a little copy-paste is a lesser evil than an unclear behavior. For all other guys the
E_NOTICE will be enough. (:
------------------------------------------------------------------------
[2017-05-11 14:28:34] olavisau at gmail dot com
BC is broken with any solution. The fact that javascript behaves in the same way worries me.
It's probably very hard to implement. I agree with the E_NOTICE.
------------------------------------------------------------------------
[2017-05-11 14:21:03] trianman at gmail dot com
> btw The behaviour in PHP is the same as that which happens in Java
> This behaviour is also that used in Javascript.
Sorry to hear that, but AFAIK nor Java nor JavaScript (ECMAScript) has no conventional
(standartized) way to produce non critical warnings at the run time.
So PHP is better in this way and why can't we employ it?
> "Don't put returns in finally"
I believe that the good tool must help its users not to "shoot themselves" as much as
possible. So the user becomes free from a lot of "Don't do something somewhere". If
you don't agree you are free to use an assembler to do anything you want and remember a lot of
such restrictions.
I can imagine another more expectable an clear way to handle this case. But it will break a BC so
can be implemented only in a new major release of PHP.
Triggering E_NOTICE is the most convenient way for now.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=74569
--
Edit this bug report at https://bugs.php.net/bug.php?id=74569&edit=1