On Sun, Jun 24, 2012 at 12:50 AM, Gustavo Lopes <glo...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
