Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119105
Return-Path: <tim@bastelstu.be>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 10815 invoked from network); 9 Dec 2022 16:31:09 -0000
Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5)
  by pb1.pair.com with SMTP; 9 Dec 2022 16:31:09 -0000
Received: from php-smtp4.php.net (localhost [127.0.0.1])
	by php-smtp4.php.net (Postfix) with ESMTP id 6D0E6180507
	for <internals@lists.php.net>; Fri,  9 Dec 2022 08:31:05 -0800 (PST)
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,
	T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2
X-Spam-ASN: AS24940 176.9.0.0/16
X-Spam-Virus: No
X-Envelope-From: <tim@bastelstu.be>
Received: from chrono.xqk7.com (chrono.xqk7.com [176.9.45.72])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by php-smtp4.php.net (Postfix) with ESMTPS
	for <internals@lists.php.net>; Fri,  9 Dec 2022 08:31:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bastelstu.be;
	s=mail20171119; t=1670603462;
	bh=aqlKc8F9luwGVSvsB0k83DZJhZtGh4lcd6rLZRoPqA4=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=O2JRe7r2uIvGfU5hXsP6ulZ4I5wUpM0akD3gKkezXE6yYNGVGUiC2YE/kIuAe3/7r
	 fEFGElLDAgwFmhWe1pjdwMR57uc8ucIIpaMqYvyXRAskyZkotOzKZznww50nGfKALo
	 TBbJTUdCfOFrJllBXSW6VAFeOe2UQVmfD+REhOqg+mDFT/pIn2oiOsQ+RBz/2yZ+ka
	 b7KgREH7nuIdiNgteX+tcWD3jB39L/0gRXUdi4Z87f1D61uSNezldXjaf7CDu8uEGc
	 kJ+D0FJgj5yTvBW9FuAFVIZ+2CXPPPGIx+xNy+qxNye28dFHUxEF5GdZQV4+dvgUp7
	 ybxGse9McMbLg==
Message-ID: <35fb3b18-79d0-4d8b-02cd-9eab0a4ecacb@bastelstu.be>
Date: Fri, 9 Dec 2022 17:31:02 +0100
MIME-Version: 1.0
Content-Language: en-US
To: Dan Ackroyd <Danack@basereality.com>
Cc: Derick Rethans <derick@php.net>,
 PHP Developers Mailing List <internals@lists.php.net>
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>
In-Reply-To: <CA+kxMuR1O19VhP3fLMkcnD4kM5yPNezwKhbMY-mZNiUNsyO-ig@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] More Appropriate Date/Time Exceptions
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

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üsterhus