Re: json_encode() behavior for incorrectly encoded strings

From: Date: Sun, 24 Jun 2012 12:12:47 +0000
Subject: Re: json_encode() behavior for incorrectly encoded strings
References: 1 2 3 4 5 6 7 8  Groups: php.internals 
Request: Send a blank email to internals+get-60955@lists.php.net to get a copy of this message
On Sun, Jun 24, 2012 at 12:50 AM, Gustavo Lopes <glopes@nebm.ist.utl.pt> wrote: > If json_encode() is not supposed to receive badly encoded data, then it's > the application writer's responsibility to make sure that the data is > correctly encoded. If, on the other hand, you think that's actually not a > error on the part of the caller to call json_encode() with badly encoded > data (i.e., just like htmlspecialchars() -- from which I removed the warning > removed in 5.4 --, json_encode() also accumulates the responsibility > validating some aspects of the input), then there's no reason to have a > warning at all. > > In other words, if it's a precondition of json_encode() that the input is > correctly encoded (and the check is just a form of safe programming), then > there's indeed an error on the part of the application writer, if it isn't, > then there's no reason for any sort of warning. > > (By the way, I'd prefer no warning at all, both for this and for inf/NAN. We > already can get the error from json_last_error() if we want to) The main problem with not throwing a warning is that it makes debugging the error quite hard. json_last_error() only gives you an error code. So you have to use some script like the one used as an example in php.net/json_last_error to figure out what the particular error code actually means. This is obviously a lot more inconvenient than simply seeing "Oh, this failed because I passed an Inf". Nikita

« previous php.internals (#60955) next »