|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #78217 set_error_handler() cannot differentiate between error and success
Submitted: 2019-06-26 12:20 UTC Modified: -
From: mikko dot rantalainen at peda dot net Assigned:
Status: Open Package: *General Issues
PHP Version: 7.2.19 OS: Ubuntu Linux 16.04 LTS
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2019-06-26 12:20 UTC] mikko dot rantalainen at peda dot net
From manual page:

Return Values
Returns a string containing the previously defined error handler (if any). If the built-in error handler is used NULL is returned. NULL is also returned in case of an error such as an invalid callback.

In practice, when a script sets an error handler the first time, the return value will always be NULL. This return value means that the call was successful OR that the call failed.

Are you serious!???!?

Could you change the behavior to return e.g. false vs null for these cases? Both would evalute to false, and if either were passed to set_error_handler() again it could restore default handler so simple code that just remembers the return value to later restore the old handler would still work as-is.

I'd suggest returning false for failed call to set_error_handler() because most code will get null from the first call anyway. As a result, more code is supposed to be dealing with null value returned here because that is the successful code path normally used.

Coders that mind about return values could do something sensible with the return value to differentiate between successful and failed call.

As things currently stand, the only way to write stable code is to call set_error_handler() once with the real parameters and store the returned value. If the returned value is null, one has to call set_error_handler() again. If the return value of the second call is null, setting the handler failed. However, if the return value of the second call is not null, the first call was successful and its return value should be used.

The ability to differentiate between successful and failed calls will be important in the future if you want to remove the already deprecated context argument.

Test script:
$rv = set_error_handler("myErrorHandler?");
echo "DEBUG: return value of set_error_handler(): ".serialize($rv)."\n";
echo "1 / 0 = ", 1/0, "\n";

function myErrorHandler($code, $message, $file, $line)
	echo "\n", __FUNCTION__, ": $file:$line: ($code) $message\n";
	exit(1); # abort

Expected result:
set_error_handler() should return something that makes it possible to differentiate between failed call and successful call.

Now the example test scripts returns null from set_error_handler() and the custom error handler never works. However, the returned null is expected value because this is the first handler for this PHP process.

If you remove the question mark from the test script, it suddenly starts to work even though the value returned by set_error_handler() is exactly the same!


Add a Patch

Pull Requests

Add a Pull Request

PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Wed May 12 20:01:28 2021 UTC