Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113409
User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd
Mime-Version: 1.0
Message-ID: <90cd28fd-f331-4f19-844b-4b03c2e7b0a8@www.fastmail.com>
In-Reply-To: 
 <CAFPFaMLhUtvygtkgWvDRYZvCc8sFNtVDiUEmAHjuXK+H=aFHbA@mail.gmail.com>
References: 
 <CAFPFaMLhUtvygtkgWvDRYZvCc8sFNtVDiUEmAHjuXK+H=aFHbA@mail.gmail.com>
Date: Sat, 06 Mar 2021 12:00:50 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: =?UTF-8?Q?Re:_[PHP-DEV]_[RFC]_Extend_error_control_operator_to_suppress_?=
 =?UTF-8?Q?exceptions?=
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Mar 4, 2021, at 8:08 AM, G. P. B. wrote:
> Hello internals,
> 
> 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
> 
> 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.
> 
> 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.
> 
> 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.
> 
> Feedback on this RFC and different ideas on how to tackle this topic are
> highly appreciated and welcomed.
> 
> Best regards,
> 
> George P. Banyard
> 
> [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

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.

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.

My first thought would be to ask if it's possible to set some contextual flag when @<Foo> 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.

Basically, my concern is that making this too easy to do:

$val = @<\Throwable> something() ?? 0;

will hide some nasty and hard to resolve performance bugs if something() ends up throwing a lot as a matter of course.

--Larry Garfield