From: mikko dot rantalainen at peda dot net
Operating system: Ubuntu Linux 16.04 LTS
PHP version: 7.2.19
Package: *General Issues
Bug Type: Bug
Bug description:set_error_handler() cannot differentiate between error and success
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 bug report at https://bugs.php.net/bug.php?id=78217&edit=1
--
Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=78217&r=trysnapshot54
Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=78217&r=trysnapshot55
Try a snapshot (trunk): https://bugs.php.net/fix.php?id=78217&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=78217&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=78217&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=78217&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=78217&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=78217&r=oldversion
Not developer issue: https://bugs.php.net/fix.php?id=78217&r=support
Expected behavior: https://bugs.php.net/fix.php?id=78217&r=notwrong
Not enough info: https://bugs.php.net/fix.php?id=78217&r=notenoughinfo
Submitted twice: https://bugs.php.net/fix.php?id=78217&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=78217&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=78217&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=78217&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=78217&r=isapi
Install GNU Sed: https://bugs.php.net/fix.php?id=78217&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=78217&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=78217&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=78217&r=mysqlcfg