Edit report at https://bugs.php.net/bug.php?id=78217&edit=1
ID: 78217
Updated by: cmb@php.net
Reported by: mikko dot rantalainen at peda dot net
Summary: set_error_handler() cannot differentiate between
error and success
-Status: Open
+Status: Verified
-Type: Bug
+Type: Documentation Problem
Package: *General Issues
Operating System: Ubuntu Linux 16.04 LTS
PHP Version: 7.2.19
Block user comment: N
Private report: N
New Comment:
As of PHP 8.0.0, set_error_handler() does no longer return NULL on
failure, but throws a TypeError. Changing the return value for
PHP-7.4 doesn't make sense so late in its release cycle. And
actually, that NULL on failure doesn't need to be documented at
all, because that is actually undefined behavior[1].
[1] <https://www.php.net/manual/en/functions.internal.php>
Previous Comments:
------------------------------------------------------------------------
[2019-06-26 12:20:24] mikko dot rantalainen at peda dot net
Description:
------------
---
From manual page: https://php.net/function.set-error-handler
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:
---------------
<?php
error_reporting(0);
$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!
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=78217&edit=1