Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60954
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.160.42 cause and error)
Message-ID: <4FE66766.2070004@lerdorf.com>
Date: Sat, 23 Jun 2012 18:03:34 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Stas Malyshev <smalyshev@sugarcrm.com>
CC: =?UTF-8?B?Sm9oYW5uZXMgU2NobMO8dGVy?= <johannes@schlueters.de>, 
 Nikita Popov <nikita.ppv@googlemail.com>,
 Daniel Convissor <danielc@analysisandsolutions.com>, 
 PHP internals <internals@lists.php.net>
References: <CAF+90c-T9hPbuS3bUxnHw-+B+Y2VLu55wQJ8UrtzrcC7TiKyVw@mail.gmail.com>  <20120621141241.GA25789@analysisandsolutions.com>  <CAF+90c8=5C_C9wa0q-Tf0OB2vKBow2PH8Nqu5n2SUm=xU1gKgQ@mail.gmail.com>  <4FE33EDF.2000409@lerdorf.com>  <CAL+t6cGZX5Db7L+0FAc7aCRXueE2O7A-_=NrmoTCteEWWkv-2w@mail.gmail.com>  <CAF+90c-NLQhGJ+H1POirt8pcxLeGBvQ5AYiBzj7Z1UOSu+YPZw@mail.gmail.com>  <4FE61E9D.5050908@sugarcrm.com>  <CAF+90c_9Sd=gHtUPc87m1Rkfp23VwNRr2Cbjchb8zfOZ1LAAzQ@mail.gmail.com> <1340492604.11164.14.camel@guybrush> <4FE64BDF.6050208@sugarcrm.com>
In-Reply-To: <4FE64BDF.6050208@sugarcrm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] json_encode() behavior for incorrectly encoded strings
From: rasmus@lerdorf.com (Rasmus Lerdorf)

On 06/23/2012 04:06 PM, Stas Malyshev wrote:
> Hi!
> 
>> Maybe it is simply time to rethink the error handling.
> 
> This is true, current error handling has many deficiencies and is also
> very expensive even when the errors are muted (we still produce the
> whole error string, etc. even if we never display it). Unfortunately, BC
> concerns prevailed last times we tried to fix it, but maybe somebody has
> new ideas on that.

Yes, I think we need to rethink warnings for the cases where the error
is part of the common use case. htmlspecialchars() getting passed
invalid Unicode chars, json_decode() getting non-json and json_encode()
getting non UTF-8 chars. These are all cases where if the function
generates an error, in order to avoid that error you have to do some
work beforehand to sanitize the input data which is a useless thing to
have to do since the functions themselves can do it.

For json_decode() we have json_last_error() to help with debugging.
Maybe a solution is to generalize that. We already mostly have it via
$php_errormsg/error_get_last().

And yes, I don't think a warning from json_encode() is useful because to
properly avoid it you would need an iconv() call before calling it and
that is pure overhead. Short of that your only recourse is to use @ and
that just isn't the right answer. In this I would suggest just having it
return false and have json_last_error() apply to json_encode() as well.

-Rasmus