> 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
