|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #76753 'Warning: "continue" targeting switch' uncatchable
Submitted: 2018-08-16 17:33 UTC Modified: 2018-08-22 21:33 UTC
Avg. Score:5.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: php at darkain dot com Assigned: cmb (profile)
Status: Closed Package: Scripting Engine problem
PHP Version: 7.3.0beta2 OS: all
Private report: No CVE-ID: None
 [2018-08-16 17:33 UTC] php at darkain dot com
Using "continue" on a "switch" statement now throws a warning. However, this warning never triggers the function specified in "set_error_handler". My unit testing framework uses "set_error_handler" to log and report any issues, but is not being triggered with this new warning.

Test script:


set_error_handler(function ($errno, $errstr, $errfile, $errline) {
	throw new ErrorException($errstr, $errno, 0, $errfile, $errline);

for ($x=0; $x<10; $x++) {
    switch ($x) {
        case 1:

Expected result:
Fatal error: Uncaught ErrorException: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"?

Actual result:
Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"?


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2018-08-16 21:59 UTC]
-Status: Open +Status: Verified
 [2018-08-16 21:59 UTC]
These warnings[1] are compile time warnings, and as such cannot be
caught by an error handler.  Their type should be
E_COMPILE_WARNING instead of E_WARNING, though.

[1] <>
 [2018-08-16 22:11 UTC] php at darkain dot com
In my particular case, the code is split between two separate files. The first file has the set_error_handler, and then AFTER that statement, there is include('other.php'), so it should still be caught (general syntax errors and all other errors/warnings are caught this way)

You can see the full file here:

Results can be found here:

(in my particular case, I found this by manually reviewing the Travis-CI reports, but because the warning was never caught, it never generated the email report saying there was an issue in the code base)
 [2018-08-17 10:00 UTC]
If I split the code[1], the ErrorException is thrown if OPcache is
disabled.  If it is enabled, the ErrorException is not thrown, but
it is also not thrown for parse errors.  That is to be expected,
though; see bug #76535.

[1] <>
 [2018-08-20 12:04 UTC]
@cmb: Making it a compile warning would make it entirely uncatchable. I don't think that there is a technical reason to use compile warnings anymore, we should probably migrate away from them in general (it used to be that invoking error handlers during compilation was unsafe, but nowadays it's no longer an issue).

As already identified, the issue here is in opcache, though not quite the same as bug #76535, which is about warnings not being thrown on subsequent accesses. The reason why the error handler is not called on the first access either is that the error handler is being unset by opcache in
 [2018-08-20 14:55 UTC]
Thanks for the explanation, Nikita.

Regarding E_COMPILE_WARNING: it's probably best to get rid of it
in PHP 8 (we're issuing that level only for a couple of things).

Regarding OPcache's temporary disabling of the error handler:
since it appears to happen for a reason, would it be possible to
store the issued warnings, and to raise them after compilation?
Otherwise this ticket should be closed as WONTFIX.
 [2018-08-20 18:02 UTC] php at darkain dot com
I think it would be best to mark this as closed now. I was not aware that this particular warning should be issued at compile time rather than run time. Knowing this, my scripts have been updated accordingly and things are fine on my end now.
 [2018-08-22 21:33 UTC]
-Status: Verified +Status: Closed -Assigned To: +Assigned To: cmb
 [2018-08-22 21:33 UTC]
Okay, closing then.
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Thu Dec 01 06:05:54 2022 UTC