Re: [VOTE] Improve unserialize() error handling
| From: | Christoph M. Becker | Date: | Sat, 15 Oct 2022 11:02:56 +0000 |
| Subject: | Re: [VOTE] Improve unserialize() error handling | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-118819@lists.php.net to get a copy of this message | ||
On 15.10.2022 at 11:06, Nicolas Grekas wrote:
>>> I'm therefore voting NO on the proposal.
>>
>> I'm not surprised by the “no” on the first vote based on the previous
>> discussion. I am surprised however that you also disagree with raising
>> the E_NOTICE to E_WARNING for consistency.
>
> Since the beginning my point is not that the RFC doesn't have merits. It's
> that the proposed approach breaks BC in a way that will affect the
> community significantly. We have policies that say we should avoid BC
> breaks and they should apply here.
Well, I consider the current behavior very unfortunate; sometimes
E_NOTICE, sometimes E_WARNING, sometimes both, and sometimes a
UnexpectedValueException – and this looks more like historic randomness
than having any deeper reasoning behind it. I also understand that we
need to be concerned about BC breaks.
So for me the question is whether we want to stick with the current
behavior *forever*, or if there is an acceptable way forward. I
certainly hope for the latter. Would it really be a serious issue to
promote E_NOTICE to E_WARNING in PHP 8.3? I don't think so, but I may
be wrong.
And would it really be a serious issue to promote E_WARNING to an
exception in PHP 9? Maybe, but after all that would be a new major
version, so some BC breaks are to be expected anyway.
--
Christoph M. Becker