php.net |  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
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: mikko dot rantalainen at peda dot net
New email:
PHP Version: OS:

 

 [2019-06-26 12:20 UTC] 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!



Patches

Add a Patch

Pull Requests

Add a Pull Request

 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Wed Sep 18 11:01:30 2019 UTC