Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119187 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 77327 invoked from network); 19 Dec 2022 15:49:14 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 19 Dec 2022 15:49:14 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 4E72A1804B0 for ; Mon, 19 Dec 2022 07:49:12 -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.5 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 19 Dec 2022 07:49:11 -0800 (PST) Received: by mail-ed1-f49.google.com with SMTP id d20so13530476edn.0 for ; Mon, 19 Dec 2022 07:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=basereality-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=V8QSobBZMnSorseAUw3lPKVQWaLOuH4LQCC8VJxWdp4=; b=SBJcT8+k3XrwwUgXngBFFG7UCJAGUm8Tgby8NI2awVHC8eQc/Hstx5+O4IhQIZUSpJ ZdcVrvPXBLHuaR8jrdnAPZN+QN3TP9rXsp7WJmmBVhjRH8lZg/uz5hTSPjvtydjht9v/ a781IlblnWARrDYS4Ed0Rf2z+MsoNL4Faj6nApvVhqz24UGzvxPGK0RzL0GQJ+yQO6PM Gironol5GhmPArNNSWNN4EvmAiK41vAupsejZRBGMigBgfw4dqa3etFlbh0W/8xfgntV bxbvlvYZ6uoq9F0leUvZNT70YQmOZ7P4apEH+xiSmNLlBbxlZ85d9B/baDMuaih8snyq 7IiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=V8QSobBZMnSorseAUw3lPKVQWaLOuH4LQCC8VJxWdp4=; b=OpMQyE4rEBkz6ht4BlnOJVr7zKafq3zFpEtMHnaSBVjhfmMfW7KMeCJCgDbGARsj8w nbhmQ36axLfqVkAT3o/I0sdXk/FRufXtjmJiArL44y+ltV3oUGiCUnqlZM6yIZ1q4+++ Xly3jSqaYojloQ2P22J3pmQKu1+IZ04qby05K4zAizCOWUQ3QRFr3f+eWu2kOV9i8KZn xDu4x7hxWzjKm3HTvAJtYo03YMLE5DLREyrPxrZwx0N9lmHpggDIt/elbOd/InOPbnjm u7numpyDU1IdhpxPWPURMEctn6g/CeIixYBCFd2jtfdpItf+FauQbJBUvOQLNRYNBaB8 C61w== X-Gm-Message-State: AFqh2kqpLmlQKnGaWu78QtbMb6nR38MknXRQYfClhJ5mw7VVErPxmJox ViZEYSPOjQi87lf360gXxv0Tn9vqkoPRSv8jcNIzN/5aWCaCZmIj X-Google-Smtp-Source: AMrXdXvvZ6YVXBtkHLKU4q8wStQ3ZfvHd6BxiD1slorzlA3uVSzrRt2GUE3W0b4O9HbtDUGH7iOk639nLDcMnKNZDCI= X-Received: by 2002:a05:6402:1158:b0:472:9aa4:161e with SMTP id g24-20020a056402115800b004729aa4161emr2618882edw.367.1671464950492; Mon, 19 Dec 2022 07:49:10 -0800 (PST) MIME-Version: 1.0 References: <35fb3b18-79d0-4d8b-02cd-9eab0a4ecacb@bastelstu.be> In-Reply-To: Date: Mon, 19 Dec 2022 15:48:59 +0000 Message-ID: To: Robert Landers , =?UTF-8?Q?Tim_D=C3=BCsterhus?= Cc: PHP Developers Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [RFC] More Appropriate Date/Time Exceptions From: Danack@basereality.com (Dan Ackroyd) On Sat, 10 Dec 2022 at 10:06, Robert Landers wro= te: > > However, I generally feel that the program will always have access to > the raw data, after all, it is unserializing it. Not always in a useful way. function getMeeting(DB $db, int $meeting_id): Meeting { $meeting_data =3D $db->getUserSettings($meeting_id); return unserialize($meeting_data); } If the $meeting_data included invalid DateTime info, the info wouldn't be in the stacktrace. Investigating that issue would require someone manually extracting some data from the production DB, which programmers shouldn't have direct access to. Tim D=C3=BCsterhus wrote: > > 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. When the info isn't completely contained in the exception message itself, what tickles my fancy is having small functions that format specific exception types into an easy to understand to comprehend piece of info, so that no-one has to spend time trying to read a stack-trace. > I'm against ext-specific or library-specific exception classes > for unserialization failures, Good point. I'll raise it again when there is another discussion about an UnserializeException. Although it would probably be safe to expose invalid data that was meant to be turned into a DateTime object, it's not obvious that it would be safe to increase the exposure of arbitrary data, as it might include PII data. cheers Dan Ack