Re: RFC json_validate() - status: Under Discussion
| From: | Rowan Tommins | Date: | Thu, 25 Aug 2022 20:45:36 +0000 |
| Subject: | Re: RFC json_validate() - status: Under Discussion | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-118474@lists.php.net to get a copy of this message | ||
On 25/08/2022 17:02, juan carlos morales wrote:
I am glad to present to you the RFC for json_validate() function. RFC: https://wiki.php.net/rfc/json_validateHi, Leaving aside the overall question of inclusion and looking at details, I'm not convinced JSON_THROW_ON_ERROR belongs here. With json_decode, throwing an exception is a useful feature because a) there is no natural value to signal an error, false and null both being valid results; and b) most code is written expecting the input to be valid, so failure is an "exceptional state" that needs to break out of normal flow. With json_validate, neither reason applies: there is no ambiguity in what false means, and no reason to write code that calls json_validate but doesn't check that return value. On a different note, I notice that several of your examples are not actually checking the validity of JSON at all, they are parsing it in order to re-serialize it - the Magento getJSONString, the Symfony getPrettyJson, and the humhub actionIndex functions are all directly using the output of json_decode, not just reporting whether it succeeded. There's still plenty of other examples that make your point, but those three should probably be removed. Regards, -- Rowan Tommins [IMSoP]