[PHP-DOC] #31919 [Opn]: E_STRICT errors are passed to custom error handler
ID: 31919
User updated by: joh at deworks dot net
Reported By: joh at deworks dot net
Status: Open
Bug Type: Documentation problem
Operating System: Linux
PHP Version: Irrelevant
New Comment:
How can this be a documentation problem when the script behaves as
expected, and as documented, when the code triggering the E_STRICT
appears inside the same file as the set_error_handler() call, but not
when it is included from another file? What we have here is conflicting
behaviour, and updating the documentation is not going to fix it
(because E_STRICT errors are not handled by a custom error handler when
they appear in the same file as the set_error_handler()).
Previous Comments:
[2005-02-11 08:11:34] [EMAIL PROTECTED]
I appreciate your reasoning behind labeling it as a scripting engine
problem, but the solution really lies in updating the documentation.
Good analysis of the root cause though.
[2005-02-10 21:18:13] joh at deworks dot net
Description:
E_STRICT errors are passed to a custom error handler when the errors
appear in an included file.
The documentation for set_error_handler() clearly states that The
following error types cannot be handled with a user defined function:
E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR,
E_COMPILE_WARNING, and E_STRICT.
This is true, if the error occurs in the same file as the error
handler, but when a file which triggers an E_STRICT warning is
included, PHP passes the error to the custom error handler. As this
only happens when including an erroneous file, I'm reporting this bug
as a Scripting Engine problem, and not a Documentation problem.
I've tested this on the latest 5.1.0 (200502101130) development
snapshot.
Reproduce code:
---
errorhandler.php:
?php
function errorHandler($severity, $message, $file = null, $line = null,
$context = array())
{
static $severityMap = array(
E_ERROR = 'E_ERROR',
E_WARNING = 'E_WARNING',
E_PARSE = 'E_PARSE',
E_NOTICE= 'E_NOTICE',
E_CORE_ERROR= 'E_CORE_ERROR',
E_CORE_WARNING = 'E_CORE_WARNING',
E_COMPILE_ERROR = 'E_COMPILE_ERROR',
E_COMPILE_WARNING = 'E_COMPILE_WARNING',
E_USER_ERROR= 'E_USER_ERROR',
E_USER_WARNING = 'E_USER_WARNING',
E_USER_NOTICE = 'E_USER_NOTICE',
E_STRICT= 'E_STRICT'
);
echo 'strong' . __METHOD__ . ': PHP Error with severity ' .
$severityMap[$severity] . '(' . $severity . ') raised: ' . $message .
/strongbr /;
}
set_error_handler('errorHandler');
include 'strict.php';
?
strict.php:
?php
class Foo {
public function __construct() { }
public function Foo() { }
}
?
Expected result:
Strict Standards: Redefining already defined constructor for class Foo
in strict.php on line 4
Actual result:
--
errorHandler: PHP Error with severity E_STRICT(2048) raised: Redefining
already defined constructor for class Foo
--
Edit this bug report at http://bugs.php.net/?id=31919edit=1
[PHP-DOC] #31919 [Opn]: E_STRICT errors are passed to custom error handler
ID: 31919
Updated by: [EMAIL PROTECTED]
Reported By: joh at deworks dot net
Status: Open
-Bug Type: Scripting Engine problem
+Bug Type: Documentation problem
Operating System: Linux
PHP Version: Irrelevant
New Comment:
I appreciate your reasoning behind labeling it as a scripting engine
problem, but the solution really lies in updating the documentation.
Good analysis of the root cause though.
Previous Comments:
[2005-02-10 21:18:13] joh at deworks dot net
Description:
E_STRICT errors are passed to a custom error handler when the errors
appear in an included file.
The documentation for set_error_handler() clearly states that The
following error types cannot be handled with a user defined function:
E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR,
E_COMPILE_WARNING, and E_STRICT.
This is true, if the error occurs in the same file as the error
handler, but when a file which triggers an E_STRICT warning is
included, PHP passes the error to the custom error handler. As this
only happens when including an erroneous file, I'm reporting this bug
as a Scripting Engine problem, and not a Documentation problem.
I've tested this on the latest 5.1.0 (200502101130) development
snapshot.
Reproduce code:
---
errorhandler.php:
?php
function errorHandler($severity, $message, $file = null, $line = null,
$context = array())
{
static $severityMap = array(
E_ERROR = 'E_ERROR',
E_WARNING = 'E_WARNING',
E_PARSE = 'E_PARSE',
E_NOTICE= 'E_NOTICE',
E_CORE_ERROR= 'E_CORE_ERROR',
E_CORE_WARNING = 'E_CORE_WARNING',
E_COMPILE_ERROR = 'E_COMPILE_ERROR',
E_COMPILE_WARNING = 'E_COMPILE_WARNING',
E_USER_ERROR= 'E_USER_ERROR',
E_USER_WARNING = 'E_USER_WARNING',
E_USER_NOTICE = 'E_USER_NOTICE',
E_STRICT= 'E_STRICT'
);
echo 'strong' . __METHOD__ . ': PHP Error with severity ' .
$severityMap[$severity] . '(' . $severity . ') raised: ' . $message .
/strongbr /;
}
set_error_handler('errorHandler');
include 'strict.php';
?
strict.php:
?php
class Foo {
public function __construct() { }
public function Foo() { }
}
?
Expected result:
Strict Standards: Redefining already defined constructor for class Foo
in strict.php on line 4
Actual result:
--
errorHandler: PHP Error with severity E_STRICT(2048) raised: Redefining
already defined constructor for class Foo
--
Edit this bug report at http://bugs.php.net/?id=31919edit=1
[PHP-DOC] #31919 [Opn]: E_STRICT errors are passed to custom error handler
ID: 31919
Updated by: [EMAIL PROTECTED]
Reported By: joh at deworks dot net
Status: Open
Bug Type: Documentation problem
Operating System: Linux
PHP Version: Irrelevant
New Comment:
It all depends on how you define consistent...
The E_STRICT gets passed on to a custom error handler if the custom
error handler is defined when it's thrown. Currently all E_STRICT
errors are thrown at compile time, for the main page compilation
happens before the set_error_handler() can ever be called. For the
included files this (may) be after the error handler is defined.
Additionally, future E_STRICT errors may be thrown at run time so you
could even see them in a main file at some point.
Lastly, it doesn't make sense to go out of the way to forcibly mask
errors when they can be caught.
If you want to avoid it in your own code, just use the optional second
parameter to set_error_handler() and make the behavior match your
definition of consistency.
Previous Comments:
[2005-02-11 15:54:58] joh at deworks dot net
How can this be a documentation problem when the script behaves as
expected, and as documented, when the code triggering the E_STRICT
appears inside the same file as the set_error_handler() call, but not
when it is included from another file? What we have here is conflicting
behaviour, and updating the documentation is not going to fix it
(because E_STRICT errors are not handled by a custom error handler when
they appear in the same file as the set_error_handler()).
[2005-02-11 08:11:34] [EMAIL PROTECTED]
I appreciate your reasoning behind labeling it as a scripting engine
problem, but the solution really lies in updating the documentation.
Good analysis of the root cause though.
[2005-02-10 21:18:13] joh at deworks dot net
Description:
E_STRICT errors are passed to a custom error handler when the errors
appear in an included file.
The documentation for set_error_handler() clearly states that The
following error types cannot be handled with a user defined function:
E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR,
E_COMPILE_WARNING, and E_STRICT.
This is true, if the error occurs in the same file as the error
handler, but when a file which triggers an E_STRICT warning is
included, PHP passes the error to the custom error handler. As this
only happens when including an erroneous file, I'm reporting this bug
as a Scripting Engine problem, and not a Documentation problem.
I've tested this on the latest 5.1.0 (200502101130) development
snapshot.
Reproduce code:
---
errorhandler.php:
?php
function errorHandler($severity, $message, $file = null, $line = null,
$context = array())
{
static $severityMap = array(
E_ERROR = 'E_ERROR',
E_WARNING = 'E_WARNING',
E_PARSE = 'E_PARSE',
E_NOTICE= 'E_NOTICE',
E_CORE_ERROR= 'E_CORE_ERROR',
E_CORE_WARNING = 'E_CORE_WARNING',
E_COMPILE_ERROR = 'E_COMPILE_ERROR',
E_COMPILE_WARNING = 'E_COMPILE_WARNING',
E_USER_ERROR= 'E_USER_ERROR',
E_USER_WARNING = 'E_USER_WARNING',
E_USER_NOTICE = 'E_USER_NOTICE',
E_STRICT= 'E_STRICT'
);
echo 'strong' . __METHOD__ . ': PHP Error with severity ' .
$severityMap[$severity] . '(' . $severity . ') raised: ' . $message .
/strongbr /;
}
set_error_handler('errorHandler');
include 'strict.php';
?
strict.php:
?php
class Foo {
public function __construct() { }
public function Foo() { }
}
?
Expected result:
Strict Standards: Redefining already defined constructor for class Foo
in strict.php on line 4
Actual result:
--
errorHandler: PHP Error with severity E_STRICT(2048) raised: Redefining
already defined constructor for class Foo
--
Edit this bug report at http://bugs.php.net/?id=31919edit=1
[PHP-DOC] #31919 [Opn]: E_STRICT errors are passed to custom error handler
ID: 31919
User updated by: joh at deworks dot net
Reported By: joh at deworks dot net
Status: Open
Bug Type: Documentation problem
Operating System: Linux
PHP Version: Irrelevant
New Comment:
Ah, now I understand. Thank you for clearing that up for me! And, yes,
the behaviour of the E_STRICT messages does not match my definition of
consistency... IMHO throwing them at runtime is a better idea.
Previous Comments:
[2005-02-11 21:52:51] [EMAIL PROTECTED]
It all depends on how you define consistent...
The E_STRICT gets passed on to a custom error handler if the custom
error handler is defined when it's thrown. Currently all E_STRICT
errors are thrown at compile time, for the main page compilation
happens before the set_error_handler() can ever be called. For the
included files this (may) be after the error handler is defined.
Additionally, future E_STRICT errors may be thrown at run time so you
could even see them in a main file at some point.
Lastly, it doesn't make sense to go out of the way to forcibly mask
errors when they can be caught.
If you want to avoid it in your own code, just use the optional second
parameter to set_error_handler() and make the behavior match your
definition of consistency.
[2005-02-11 15:54:58] joh at deworks dot net
How can this be a documentation problem when the script behaves as
expected, and as documented, when the code triggering the E_STRICT
appears inside the same file as the set_error_handler() call, but not
when it is included from another file? What we have here is conflicting
behaviour, and updating the documentation is not going to fix it
(because E_STRICT errors are not handled by a custom error handler when
they appear in the same file as the set_error_handler()).
[2005-02-11 08:11:34] [EMAIL PROTECTED]
I appreciate your reasoning behind labeling it as a scripting engine
problem, but the solution really lies in updating the documentation.
Good analysis of the root cause though.
[2005-02-10 21:18:13] joh at deworks dot net
Description:
E_STRICT errors are passed to a custom error handler when the errors
appear in an included file.
The documentation for set_error_handler() clearly states that The
following error types cannot be handled with a user defined function:
E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR,
E_COMPILE_WARNING, and E_STRICT.
This is true, if the error occurs in the same file as the error
handler, but when a file which triggers an E_STRICT warning is
included, PHP passes the error to the custom error handler. As this
only happens when including an erroneous file, I'm reporting this bug
as a Scripting Engine problem, and not a Documentation problem.
I've tested this on the latest 5.1.0 (200502101130) development
snapshot.
Reproduce code:
---
errorhandler.php:
?php
function errorHandler($severity, $message, $file = null, $line = null,
$context = array())
{
static $severityMap = array(
E_ERROR = 'E_ERROR',
E_WARNING = 'E_WARNING',
E_PARSE = 'E_PARSE',
E_NOTICE= 'E_NOTICE',
E_CORE_ERROR= 'E_CORE_ERROR',
E_CORE_WARNING = 'E_CORE_WARNING',
E_COMPILE_ERROR = 'E_COMPILE_ERROR',
E_COMPILE_WARNING = 'E_COMPILE_WARNING',
E_USER_ERROR= 'E_USER_ERROR',
E_USER_WARNING = 'E_USER_WARNING',
E_USER_NOTICE = 'E_USER_NOTICE',
E_STRICT= 'E_STRICT'
);
echo 'strong' . __METHOD__ . ': PHP Error with severity ' .
$severityMap[$severity] . '(' . $severity . ') raised: ' . $message .
/strongbr /;
}
set_error_handler('errorHandler');
include 'strict.php';
?
strict.php:
?php
class Foo {
public function __construct() { }
public function Foo() { }
}
?
Expected result:
Strict Standards: Redefining already defined constructor for class Foo
in strict.php on line 4
Actual result:
--
errorHandler: PHP Error with severity E_STRICT(2048) raised: Redefining
already defined constructor for class Foo
--
Edit this bug report at http://bugs.php.net/?id=31919edit=1
