As Rowan has addressed your first points, I'll skip them but will add a code example to clarify in the RFC.
On Fri, 5 Mar 2021 at 04:26, Mike Schinkel <m...@newclarity.net> wrote: > > 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. > > Would you also consider adding a reciprocal `error_on_exception` declare? > I would not, as diagnostics (I've started to really despise the wording error/traditional error for E_NOTICE/E_WARNING and co) can always be elevated back to an exception by using a custom error handler.Now in theory the opposite is also true you can set an exception handler and raise an E_WARNING, but this is mostly a useless operation as you're already at the top of the execution stack. Because of that, any time a diagnostic might be emitted the VM needs to perform extra checks to see if it wasn't elevated to an exception and perform some special care handling.As such a declare which would toggle all exceptions to diagnostics is a very bad idea IMHO.Even if this is just limited to functions/methods and not language constructs, emitting a diagnostic is usually subpar as to analyse an error one must do extra steps (reading error_get_last() and branching, etc.)It is true that exceptions can be overused/abused, but they are IMHO far superior to diagnostics. > 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. > > What do you see as the downside of shoving more functionality into @? Is > the concern anything more than making the source for PHP more complicated > to maintain? > > Other than the BC break I think there is also the fact that the @ operator has a "bad" reputation and users went to great lengths to *not* use it by utilizing various tricks. And starting now to *promote* the usage of it again could be seen as a net negative by many people, especially as being able to use it to completely ignore any sort of Throwable error (be it a subclass of Error which should probably never be caught and ignored, or a subclass of Exception where it usually would make sense) in such an "easy" manner could lead to overusing exceptions for dataflow although exceptions (at least how my PoC is currently implemented) are still expensive to create just to be tossed away immediately. Best regards, George P. Banyard
