Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119106
MIME-Version: 1.0
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>
In-Reply-To: <35fb3b18-79d0-4d8b-02cd-9eab0a4ecacb@bastelstu.be>
Date: Sat, 10 Dec 2022 11:05:53 +0100
Message-ID: <CAPzBOBP4RYNMy2w3FDdOn8924Ja=z0MxKf3NNDKnf1wCYJwhEg@mail.gmail.com>
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] More Appropriate Date/Time Exceptions
From: landers.robert@gmail.com (Robert Landers)

On Fri, Dec 9, 2022 at 5:31 PM Tim D=C3=BCsterhus <tim@bastelstu.be> wrote:
>
> Hi
>
> 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 corrupted
> > so that you can stop it from happening again. And doing that would
> > rely on being able to see the data that you attempted to unserialize.
>
> That's fair, but does not require dedicated subclasses. Investigating
> corrupted serialization data is not something that can be done
> programmatically, instead an actual human has to look at the error
> message and possibly stack trace within the error log / within Sentry /
> whatever floats your boat.
>
> I'm not against improving the error messages to more clearly indicate
> what part of the serialized data is broken, I'm against ext-specific or
> library-specific exception classes for unserialization failures, because
> that will lead to assumptions being made that will not hold in the
> general case.
>
> Best regards
> Tim D=C3=BCsterhus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

I feel like the RFC could use a bit more clarity around what
"unserialize" means. Are we talking about the literal "unserialize()"
function, or are we also talking about unserializing a string into a
DateTimeInterface object? I took it to mean the latter, and if the
latter, then I think putting the original data in the error object is
quite important. It's important for generating user-submitted errors,
reading data from a database/cache, or other messages.

However, I generally feel that the program will always have access to
the raw data, after all, it is unserializing it. If the
application/framework/whatever wants to log it, it should be able to
do that without PHP's help.

-- Rob