Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119101 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 20705 invoked from network); 8 Dec 2022 15:05:44 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 8 Dec 2022 15:05:44 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 6944C180554 for ; Thu, 8 Dec 2022 07:05:43 -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=-0.7 required=5.0 tests=BAYES_05,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: 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 ; Thu, 8 Dec 2022 07:05:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bastelstu.be; s=mail20171119; t=1670511940; bh=IYjYbVkFfZWy06dU9VHMLRsK+5SNkToUSYV0ueCSbz0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=HyOR4nqYo9nawuGf3O3zODFlYA7WvVbSWvX0qzCWLGj0g2Ya6YNCujJsexH8if4a5 ErIiutXGI06vb2O7auIyg1D5CpABzxKk9u7PS6Qa57uIuAyIsspF3Fu9zl5Cl644sj z4DjEGyw4D7asdmI/k4KaTTFuUgi2R9Bx7fEQTkfbj8zolIxXkXNXZpc5JrRdIXyzZ nn0s1DnKEpM5oBRpNKLCGy8c8nsM6rhi07BKn/tctayuMXx0pVNP5GtYMdK8ZU2G8l Rp1anwQKy4HxnITqXUq7J/LItEcIKbPPESW4fscn9ZCTVt8CFL1iBAVqyIl0RduChU AVqZQGg6m7Yzw== Message-ID: Date: Thu, 8 Dec 2022 16:05:38 +0100 MIME-Version: 1.0 Content-Language: en-US To: Dan Ackroyd , Derick Rethans Cc: PHP Developers Mailing List References: In-Reply-To: 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/8/22 15:11, Dan Ackroyd wrote: > None of the 'Invalid serialization' errors tell the programmer who > reads them what is wrong with the data. > > Unless the code was written in such a way that the data was in (and > was logged) in the callstack, that would be a bit frustrating as > someone might need to do quite a bit of work to find the data that was > triggering the problem. > > Changing those to be specific error type, that included a method of > 'getBadData' could make it easier to fix those issues. > *Strong* disagree, because: https://wiki.php.net/rfc/improve_unserialize_error_handling. We should not make it easier for developers to programmatically shoot themselves in their feet with unserialize(). If your data fails to unserialize, the only safe option is to throw it away. Best regards Tim Düsterhus