Edit report at https://bugs.php.net/bug.php?id=61747&edit=1
ID: 61747
User updated by: chealer at gmail dot com
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:
No what? It's not fine not to treat suppressed errors differently?
Previous Comments:
------------------------------------------------------------------------
[2012-04-17 02:00:40] [email protected]
No, I think a custom error handler should make good use of the silence
operator.
There are all kinds of interesting things you can do with it. But yes, if you
want to ignore it entirely, that is fine too.
------------------------------------------------------------------------
[2012-04-17 01:40:34] chealer at gmail dot com
Right. So, the documentation is saying custom error handlers should treat
suppressed errors differently. You are saying it is fine not to do that.
I think your version is right.
------------------------------------------------------------------------
[2012-04-17 00:59:34] [email protected]
Right, it says "should" not "must". If you choose to not treat @ differently,
then you obviously don't need to call error_reporting() from your handler.
------------------------------------------------------------------------
[2012-04-17 00:36:29] chealer at gmail dot com
You write:
If you choose to treat @-preceded errors like any other error, that's fine.
Yet http://ca3.php.net/manual/en/language.operators.errorcontrol.php says a
custom error handler should call error_reporting().
So why should a custom error handler which chooses to treat @-preceded errors
like any other error call error_reporting()?
You write:
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.
I'm not sure I would say that custom error handlers *should* have the power to
override error suppression, but I certainly understand that it can be useful.
In any case, offering that flexibility doesn't have to make it more complicated
to write a simple custom handler. set_error_handler() could simply have an
argument to control whether the callback is called even on normally suppressed
errors.
------------------------------------------------------------------------
[2012-04-16 22:34:14] [email protected]
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.
------------------------------------------------------------------------
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
