Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113412 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 30417 invoked from network); 6 Mar 2021 22:08:12 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 6 Mar 2021 22:08:12 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 03B211804C3 for ; Sat, 6 Mar 2021 13:59:32 -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=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-qt1-f193.google.com (mail-qt1-f193.google.com [209.85.160.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 6 Mar 2021 13:59:31 -0800 (PST) Received: by mail-qt1-f193.google.com with SMTP id 18so4763137qty.3 for ; Sat, 06 Mar 2021 13:59:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=RkDmK++IsWsK2kKKY/ZntKLE9rBp6PWex840QZWO/kE=; b=ila4/l3uPJfBjJLjzoGbjb1VKYxs4Ez30pCWwE7jF5WjUXL7nJrl4sIZNh9dnWhSaP sQZGss1r9TyV9I/q/s9FFQ9y1UlVR9LGbGOwa9hUfjtmBCRs3RZDJ+Mvxt7NPJmqRfN+ H2NnvJxrAToA+tnvjyce3zqGbsLBQ1rLYrtT0FfaXPWsH6brkAH9LbBqRUXw3ZVIO7ii pPSd0YZbqgbCAWMsJohgSyl4nrjEGX4YpBYAUS55t7IfxKw05nRzuGIMuiUpFDtERBlZ CB2EH283RrmkTnqP40Cq2JEoAj5p8j+vj2S61Nk9dmcpQRCdLrNnFgQC0khfjiL8hW14 MPxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=RkDmK++IsWsK2kKKY/ZntKLE9rBp6PWex840QZWO/kE=; b=ItJ/c6POVAB3lqZbnB2IzbEjC1Bi49Cz5Ihg1lzivbmO5DPVJGXbIDuHTLzlzundpx cfPja+hvr1jwA/4d0+anoCJxLTJcXvT6Dfq2RkM4zLpXjFDo5qX5Aj9uaKVPM7cqW360 gVvkZzH2ptYz9OBfozYWzXDZNZHy7k9eNemqGHS0Z7jsD8jedYMFr+gXvS7QNeRxW9Mi xOm/tGPBM7FfcZoF5S8O4OGFNKd8Lay7sYQnRZ95nIeDyjFrzwFZA4OOdmIouHpTyaqX ZRPMqkvnd5/sadW7bV/TlyUBCz8OdPiXG3GtjE14dPJ8DKnIa6JdDoJC9WosX9VqjSLy efbQ== X-Gm-Message-State: AOAM531JzLykO69oGoiP8GjZUsQXzek/73cUY544q7IjhhOU5vr/LwrC OxWCz2owPzLhngFGdRFBteHtSoHMSL9TbE59 X-Google-Smtp-Source: ABdhPJyG8PUuPudB7uv3Azpog3FofII/tkpwII8h/TatZrKS5R3n7dE1V9KlePom/VYLJx1VsX8/1g== X-Received: by 2002:ac8:649:: with SMTP id e9mr14946667qth.114.1615067968543; Sat, 06 Mar 2021 13:59:28 -0800 (PST) Received: from [192.168.1.239] (c-24-98-254-8.hsd1.ga.comcast.net. [24.98.254.8]) by smtp.gmail.com with ESMTPSA id h3sm4664568qtp.8.2021.03.06.13.59.28 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Mar 2021 13:59:28 -0800 (PST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sat, 6 Mar 2021 16:59:27 -0500 References: <90cd28fd-f331-4f19-844b-4b03c2e7b0a8@www.fastmail.com> To: php internals In-Reply-To: <90cd28fd-f331-4f19-844b-4b03c2e7b0a8@www.fastmail.com> Message-ID: X-Mailer: Apple Mail (2.3608.120.23.2.4) Subject: Re: [PHP-DEV] [RFC] Extend error control operator to suppress exceptions From: mike@newclarity.net (Mike Schinkel) > On Mar 6, 2021, at 1:00 PM, Larry Garfield = wrote: >=20 > On Thu, Mar 4, 2021, at 8:08 AM, G. P. B. wrote: >> Hello internals, >>=20 >> This new RFC which I'm proposing is to extend the capability of the = error >> control operator @ to not just suppress diagnostic messages but also >> exceptions. >> It can currently be found on GitHub: [1] >> https://github.com/Girgias/error-control-operator-exceptions-rfc >>=20 >> The main motivation for this is to provide a path to migrate in a = backwards >> compatible manner away from diagnostics such as E_WARNING to the use = of >> exceptions without breaking 99% of PHP code which has been written in = the >> last 25years. >>=20 >> This proposal on it's own would not be sufficient to trigger such a = change >> for extensions but in combination with another proposal to introduce = a >> `throw_on_error` declare [2] it could provide a bridge for a gradual >> transition to the use of more exceptions internally. >>=20 >> Although I'm not thrilled with the idea of shoving more functionality = into >> @ I don't see any other way, and thus I think it a necessary evil to >> improve the long term health of the PHP project. >>=20 >> Feedback on this RFC and different ideas on how to tackle this topic = are >> highly appreciated and welcomed. >>=20 >> Best regards, >>=20 >> George P. Banyard >>=20 >> [1] https://github.com/Girgias/error-control-operator-exceptions-rfc >> [2] Draft RFC for throw_on_error declare >> https://github.com/Girgias/php-rfc-throw-on-error-declare >=20 > My first thought is that if you're throwing away exceptions, you're = therefore performing an expensive operation (generating a backtrace for = the exception) that will then be discarded, and thus is wasted effort. >=20 > If people start using this frequently as a short-hand that allows = exceptions as a bail-out flow contrl (whether that's good or bad, = overall), that means you could end up with unexpectedly slow code that = generates lots of expensive exceptions for no purpose. >=20 > My first thought would be to ask if it's possible to set some = contextual flag when @ is used, such that code executed in that = scope will not generate a backtrace and instead throw some kind of thin = exception that has only the cheap bits in it, making it less expensive. = Of course, I realize that may also end up encouraging people to use = exceptions for flow control, which is not ideal. If a thin exception were used, let's say maybe Exception were modified = to move message, code, file and line to a Notice class and then = Exception extended Notice then would using Notice for flow control = actually still be using exceptions? =20 Or would it not instead be using error handling more like how Go uses = error handling, with objects that simply provide access to the = information that caused the calling function to not complete as = expected? >=20 > Basically, my concern is that making this too easy to do: >=20 > $val =3D @<\Throwable> something() ?? 0; >=20 > will hide some nasty and hard to resolve performance bugs if = something() ends up throwing a lot as a matter of course. >=20 > --Larry Garfield -Mike=