Edit report at https://bugs.php.net/bug.php?id=61091&edit=1
ID: 61091
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.3.10
Block user comment: N
Private report: N
New Comment:
I understand that this problem only happens when using a custom error handler.
But, if we assume the bug is in the documentation, the documentation should not
assume the error handler used is the standard one. The problem I'm reporting
here is not that the documentation doesn't explain how custom error handlers
should be written, it's just the quoted statement, which is wrong in certain
cases.
Alternatively, if the documentation of the @ operator isn't amended because
custom error handlers are considered a corner case, then the
set_error_handler() documentation should warn developers tempted to use custom
error handlers that they are non-standard, not recommended/supported, and try
to explain the pitfalls. In short, tell developers they should only use a
custom error handler if they know what they're doing.
However, this alternative should be avoided since set_error_handler() is
already used in several applications whose developers didn't receive the
warning.
Previous Comments:
------------------------------------------------------------------------
[2012-02-19 22:38:57] [email protected]
But it is unless you choose to override the default behaviour. And the
documentation you hit when you do this override tells you how to check for @.
------------------------------------------------------------------------
[2012-02-19 21:59:53] chealer at gmail dot com
I guess it does, but this report is not about error_reporting, it is about the
@ error control operator.
According to the documentation of @, any error message that might be generated
by the expression will be "ignored". Either the PHP interpreter is changed so
that this becomes the case, or, if the current behavior is desired, the
documentation is adapted to reflect the actual semantics.
To be perfectly clear, I am not asking to change the de facto semantics. I am
only asking that whatever semantics is used by the implementation matches the
documented semantics.
------------------------------------------------------------------------
[2012-02-19 20:24:52] [email protected]
It says, "however you are still able to read the current value of
error_reporting
and act appropriately" followed by "Of particular note is that this value will
be
0 if the statement that caused the error was prepended by the @ error-control
operator."
To me this says quite clearly that error_reporting will be 0 if the @ was used
and that your custom error handler can read this value and "act appropriately."
------------------------------------------------------------------------
[2012-02-19 19:49:22] chealer at gmail dot com
Rasmus, the part you quoted is about error_reporting() settings, it merely
mentions the error control operator.
My question was, could you quote where "http://www.php.net/set_error_handler
[...] explains that the user-defined error
handler should check the error_reporting level in order to comply with the '@'
if so desired"?
------------------------------------------------------------------------
[2012-02-15 16:53:06] [email protected]
"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 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=61091
--
Edit this bug report at https://bugs.php.net/bug.php?id=61091&edit=1
