Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118567
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-927-gf4c98c8499-fm-20220826.002-gf4c98c84
Mime-Version: 1.0
Message-ID: <628f27cd-d7f0-4a75-bf5b-f4812ff459a5@www.fastmail.com>
In-Reply-To: <530b3a9d-0ee4-6061-8c69-df672d238032@bastelstu.be>
References: <530b3a9d-0ee4-6061-8c69-df672d238032@bastelstu.be>
Date: Mon, 05 Sep 2022 16:12:18 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC [Discussion]: Improve unserialize() error handling
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Sep 5, 2022, at 12:20 PM, Tim D=C3=BCsterhus wrote:
> Hi
>
> I've now written up an RFC as a follow-up for the "What type of=20
> Exception to use for unserialize() failure?" thread [1]:
>
> ----
>
> RFC: Improve unserialize() error handling
> https://wiki.php.net/rfc/improve_unserialize_error_handling
>
> Proof of concept implementation is in:
>
> https://github.com/php/php-src/pull/9425
>
> Discussion period for that RFC is officially opened up.
>
> ----
>
> The primary point of discussion in the previous mailing list thread an=
d=20
> in the PR comments is whether unserialize() should continue to emit=20
> E_WARNING or whether that should consistently be changed to an=20
> Exception. As of now I plan to explicitly vote on this and the RFC=20
> contains some opinions on that matter.
>
> Best regards
> Tim D=C3=BCsterhus
>
> [1] https://externals.io/message/118311

Well-explained and well-argued.  The only thing I'd add is that we shoul=
d consider bumping the E_NOTICE to an E_WARNING, *and* slating it to inc=
rease to an exception in 9.0.  This feels like a smaller BC concern than=
 most, but people are extra sensitive these days about those edge cases =
so it's probably good to be cautious.

--Larry Garfield