Edit report at https://bugs.php.net/bug.php?id=63004&edit=1
ID: 63004
Comment by: david at grudl dot com
Reported by: juzna dot cz at gmail dot com
Summary: errors json_encode do NOT call error handler
Status: Not a bug
Type: Bug
Package: JSON related
Operating System: Ubuntu 10.04
PHP Version: 5.4.6
Block user comment: N
Private report: N
New Comment:
ad "in PHP 5.5 the behavior here changes ⦠error will be available via
json_last_error()"
Functions like mysql_error(), socket_last_error(), preg_last_error() etc are
very unreliable because:
1) you are never sure the error-code was correctly reseted.
example 1:
json_decode('***'); // error, json_last_error() returns 4
json_decode(''); // correct, but it resets json_last_error() only since PHP
5.3.7
example 2:
preg_match('#.#u', "\xCA"); // error, preg_last_error() returns 4
preg_match("#\xCA#u", ''); // error too, but it DO NOT (re)set preg_last_error()
echo preg_last_error(); // preg_last_error() still returns 4
2) sometimes it is impossible to say what is "last" error
$s = preg_replace_callback($pattern, $callback, $s);
if (preg_last_error()) {
// was error in this preg_replace_callback or was PCRE used in $callback?
Nobody knows...
}
Everything can be solved by converting warnings to exceptions via
set_error_handle(). So I hope it will possible in PHP 5.5.
Previous Comments:
------------------------------------------------------------------------
[2012-09-04 12:03:21] david at grudl dot com
Common way to avoid warnings in PHP is to use shut-up operator:
$handle = @fopen($file, 'r');
It is not ideal solution, but it is used in whole PHP. Standard. With just one
exception:
$old = ini_set('display_errors', 1);
$json = json_encode($args);
ini_set('display_errors', $old);
Why json_encode() is exception?
------------------------------------------------------------------------
[2012-09-04 06:01:05] [email protected]
By the way, in PHP 5.5 the behavior here changes and there is no warning at
all. The error will be available via json_last_error() and a second function
which returns a human readable string instead of an error code.
------------------------------------------------------------------------
[2012-09-04 03:28:46] [email protected]
It isn't a new mechanism for PHP. We have had things like mysql_error(),
socket_last_error(), oci_error(), ldap_error(), pg_last_error(),
libxml_get_errors(), preg_last_error(), curl_error() and many money for a very
long time.
The main reason to not surface a warning here is that the only way to avoid it
would be to call iconv('utf-8','utf-8',$str) on all strings to be encoded. This
is a huge hassle to do, it is slow, and this is something we actually do
internally in json_encode() to validate utf-8 anyway, so it would be entirely
redundant. And since in many cases you end up passing user data or at least 3rd-
party data directly to json_encode() you would have to always add this
redundant
check.
------------------------------------------------------------------------
[2012-09-04 03:17:44] david at grudl dot com
This is the only one function in whole PHP with this behaviour. So is it a new
way of error handling or bug?
------------------------------------------------------------------------
[2012-09-03 23:36:20] [email protected]
json_encode() now checks for valid utf-8. It makes no sense to generate
warnings
for core functionality of the function. You can check json_last_error() for
JSON_ERROR_UTF8 if you want to programmatically catch invalid utf-8.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=63004
--
Edit this bug report at https://bugs.php.net/bug.php?id=63004&edit=1
