php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Doc Bug #31919 E_STRICT errors are passed to custom error handler
Submitted: 2005-02-10 21:18 UTC Modified: 2005-02-14 10:02 UTC
From: joh at deworks dot net Assigned:
Status: Closed Package: Documentation problem
PHP Version: Irrelevant OS: Linux
Private report: No CVE-ID: None
View Developer Edit
 [2005-02-10 21:18 UTC] 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 . "</strong><br />";
}

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

Patches

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-02-11 08:11 UTC] pollita@php.net 
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-11 15:54 UTC] 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 21:52 UTC] pollita@php.net 
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-12 00:38 UTC] joh at deworks dot net 
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.
 [2005-02-14 10:02 UTC] vrana@php.net 
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.

set_error_handler: "The following error types cannot be handled: ... most of E_STRICT raised in the file where set_error_handler() is called."

error_reporting: "Most of E_STRICT errors are evaluated at the compile time thus such errors are not reported in the file where error_reporting is enhanced to include E_STRICT errors."
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sun Aug 18 04:01:30 2024 UTC