Re: RFC json_validate() - status: Under Discussion

> whether returning boolean is the right thing to do at all. It seems obviously > intuitive it should, returning true for valid and false for invalid JSON > but then if you consider you're still going to be in the situation of > calling json_last_error() if you want to know why invalid JSON was invalid > and in particular you might not expect the "last error" to have changed > just from an attempt to check a string. How can there be an error when by > definition you weren't trying to do anything except check the validity of > some unknown data? Not sure what the answer is there...curious what other > people's views are on that. I don't think throwing an exception on invalid > JSON is the right answer in any case. One of the reasons why I like json_validate over is_json is that the former does not imply a boolean return value as strongly as the latter. I think we should not modify any state with the json_validate function, and I'd be happy with the function returning 0 for a valid JSON, or the error code as an integer (JSON_ERROR_STATE_MISMATCH, JSON_ERROR_SYNTAX, etc.). JSON_ERROR_NONE constant is already assigned 0, so they align quite well too. As for exceptions, I too think throwing an exception here is an anti-pattern. It makes perfect sense to throw on json_decode if the program doesn't want to deal with invalid JSON gracefully. But calling json_validate is an intended call, and returning an error is excepted, and not an exception.