Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118474
Message-ID: <30876360-1d4f-8097-0b58-fd902f1fa009@gmail.com>
Date: Thu, 25 Aug 2022 21:45:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Content-Language: en-GB
To: internals@lists.php.net
References: <CANMwmbN8_Km+urXbNO7oWvNteYA2mTPNYyRgfaoypEK1Cw4F0A@mail.gmail.com>
In-Reply-To: <CANMwmbN8_Km+urXbNO7oWvNteYA2mTPNYyRgfaoypEK1Cw4F0A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC json_validate() - status: Under Discussion
From: rowan.collins@gmail.com (Rowan Tommins)

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_validate


Hi,

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]