php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #78217 set_error_handler() cannot differentiate between error and success
Submitted: 2019-06-26 12:20 UTC Modified: 2021-09-29 18:04 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: mikko dot rantalainen at peda dot net Assigned:
Status: Verified Package: *General Issues
PHP Version: 7.2.19 OS: Ubuntu Linux 16.04 LTS
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
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

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2021-09-29 18:04 UTC] cmb@php.net
-Status: Open +Status: Verified -Type: Bug +Type: Documentation Problem
 [2021-09-29 18:04 UTC] cmb@php.net
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>
 [2022-12-28 11:03 UTC] janettabloomquist at gmail dot com
The set_error_handler() function is used to tell PHP how to handle standard engine errors that are not instances of the Error exception. By default, the error handler we register is using set_error_handler() , but not passing the second $error_types argument;
(https://www.heb-partnernet.com/)github.com
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 23:01:28 2024 UTC