Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119146
Date: Thu, 15 Dec 2022 10:26:14 +0000 (GMT)
To: Robert Landers <landers.robert@gmail.com>
cc: PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <CAPzBOBP4RYNMy2w3FDdOn8924Ja=z0MxKf3NNDKnf1wCYJwhEg@mail.gmail.com>
Message-ID: <alpine.DEB.2.23.453.2212151009090.462551@singlemalt.home.derickrethans.nl>
References: <alpine.DEB.2.23.453.2211291739450.249346@singlemalt.home.derickrethans.nl> <CA+kxMuT0L9bhUV0aXvRDs8rfkmgq4i4a9r2NT-4yyVFQjBNhSA@mail.gmail.com> <a184942d-ccda-6094-87f6-659a5251a916@bastelstu.be> <CA+kxMuR1O19VhP3fLMkcnD4kM5yPNezwKhbMY-mZNiUNsyO-ig@mail.gmail.com>
 <35fb3b18-79d0-4d8b-02cd-9eab0a4ecacb@bastelstu.be> <CAPzBOBP4RYNMy2w3FDdOn8924Ja=z0MxKf3NNDKnf1wCYJwhEg@mail.gmail.com>
User-Agent: Alpine 2.23 (DEB 453 2020-06-18)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1415662903-1671099974=:462551"
Subject: Re: [PHP-DEV] [RFC] More Appropriate Date/Time Exceptions
From: derick@php.net (Derick Rethans)

--8323329-1415662903-1671099974=:462551
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Sat, 10 Dec 2022, Robert Landers wrote:

> On Fri, Dec 9, 2022 at 5:31 PM Tim D=C3=BCsterhus <tim@bastelstu.be> wrot=
e:
> >
> > On 12/9/22 17:17, Dan Ackroyd wrote:
> > >> If your data fails to
> > >> unserialize, the only safe option is to throw it away.
> > >
> > > Even given that, you probably want to investigate how it got=20
> > > corrupted so that you can stop it from happening again. And doing=20
> > > that would rely on being able to see the data that you attempted=20
> > > to unserialize.
> >
> > That's fair, but does not require dedicated subclasses.=20
> > Investigating corrupted serialization data is not something that can=20
> > be done programmatically, instead an actual human has to look at the=20
> > error message and possibly stack trace within the error log / within=20
> > Sentry / whatever floats your boat.
> >
> > I'm not against improving the error messages to more clearly=20
> > indicate what part of the serialized data is broken, I'm against=20
> > ext-specific or library-specific exception classes for=20
> > unserialization failures, because that will lead to assumptions=20
> > being made that will not hold in the general case.
>=20
> I feel like the RFC could use a bit more clarity around what=20
> "unserialize" means. Are we talking about the literal "unserialize()"=20
> function, or are we also talking about unserializing a string into a=20
> DateTimeInterface object? I took it to mean the latter, and if the=20
> latter, then I think putting the original data in the error object is=20
> quite important. It's important for generating user-submitted errors,=20
> reading data from a database/cache, or other messages.

The "Invalid serialiszation data for * object" errors (they are already=20
Error) are used in __set_state and __wakeup =E2=80=94 for for both PHP's=20
unserialize (the __wakeup) and when calling __set_state with an array=20
with values.

Currently these do not provide any other context, and although that can=20
be expanded, it is not what this RFC set out to do. I would say that=20
improving error/exception/warning messages is out of scope.

I am not saying that we shouldn't do it, but not as part of this RFC.=20
I'll reflect it to say so, as well as clarify the serialization=20
messages.

cheers,
Derick

--=20
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/suppo=
rt
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug
--8323329-1415662903-1671099974=:462551--