Edit report at https://bugs.php.net/bug.php?id=61747&edit=1
ID: 61747 Updated by: ras...@php.net Reported by: chealer at gmail dot com Summary: User-defined error handler run despite at sign (@) error control operator Status: Not a bug Type: Bug Package: *General Issues PHP Version: 5.4.0 Block user comment: N Private report: N New Comment: I didn't say that I think custom error handlers should ignore suppressed errors. I said that the authors of the custom error handlers should decide what to do with them so they should called error_reporting() and take an appropriate action. I have seen systems that use the @ to classify something that generates an E_WARNING as non-critical for example, where an E_WARNING without the @ causes someone to get paged. And it is documented on the set_error_handler() page. It says: error_reporting() settings will have no effect and your error handler will be called regardless - however you are still able to read the current value of error_reporting and act appropriately. Of particular note is that this value will be 0 if the statement that caused the error was prepended by the @ error-control operator. The point of a custom error handler is to override the default PHP error handling behaviour. By default PHP ignores errors from calls preceded by @, but since you are writing your own you should have the power to override any and all such defaults. If you choose to treat @-preceded errors like any other error, that's fine. This really isn't going to change. Previous Comments: ------------------------------------------------------------------------ [2012-04-16 21:50:00] chealer at gmail dot com I meant it would be inefficient to ask PHP programmers to include if (!(error_reporting() & $errno)) { // This error code is not included in error_reporting return; } in all custom error handlers they write, if the problem could be addressed once and for all by the PHP interpreter. If that is your stance though, this requirement should be documented in http://ca3.php.net/manual/en/function.set-error-handler.php And if you really think that custom error handlers should ignore suppressed errors, then not calling custom error handlers would be more of a bugfix (for those handlers that fail to do it) than a BC break. Certainly, that wouldn't be a "major BC break", although it may be disruptive enough to warrant waiting for a major release to do such a behavior change. I'm not saying there's something *wrong* (in the sense of buggy) with the current implementation, as long as how it works is documented (which wasn't the case until recently), and the requirement to check for suppressed errors is documented in set_error_handler()'s documentation (which is still not the case). ------------------------------------------------------------------------ [2012-04-16 21:31:03] ras...@php.net There is nothing inefficient about calling error_reporting(). It is a trivially small and fast internal function. And like I said, changing anything here would be a major BC break. There is nothing wrong with the current implementation. ------------------------------------------------------------------------ [2012-04-16 21:23:27] chealer at gmail dot com This is a duplicate of #52338. Note that I partly disagree with the fix. Custom error handlers *can* check error_reporting(), as illustrated in the example from http://ca3.php.net/manual/en/function.set-error-handler.php function myErrorHandler($errno, $errstr, $errfile, $errline) { if (!(error_reporting() & $errno)) { // This error code is not included in error_reporting return; } [...] } However, it would be rather inefficient if custom error handlers *should* (had to) do that, in general. If that was the case, PHP should simply not call user-defined error handlers when @ was used. I think user-defined error handlers *should* do something like that, but only in some cases. ------------------------------------------------------------------------ [2012-04-16 20:59:18] chealer at gmail dot com I'm sorry. This was fixed in http://svn.php.net/viewvc/phpdoc/en/trunk/language/operators.xml?r1=322134&r2=323370 We now have: When prepended to an expression in PHP, any error messages that might be generated by that expression will be ignored. If you have set a custom error handler function with set_error_handler() then it will still get called, but this custom error handler can (and should) call error_reporting() which will return 0 when the call that triggered the error was preceded by an @. Note that this second sentence contradicts the first in some [edge] cases. At least, the second sentence should immediately follow the first, rather than having its own paragraph. ------------------------------------------------------------------------ [2012-04-16 20:39:54] ras...@php.net The documentation is quite clear I think. In the first link you provided it says: If you have set a custom error handler function with set_error_handler() then it will still get called, but this custom error handler can (and should) call error_reporting() which will return 0 when the call that triggered the error was preceded by an @. I see no reason to change anything here. The current approach gives you all the control you need. If you have a custom error handler you can decide whether you want to ignore silenced calls or not. Any change to this would also be a major BC break. ------------------------------------------------------------------------ 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=61747 -- Edit this bug report at https://bugs.php.net/bug.php?id=61747&edit=1