> On Mar 6, 2021, at 10:30 AM, G. P. B. <[email protected]> wrote:
>
> 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 <[email protected]
> <mailto:[email protected]>> 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.
Thank you for responding to this. However, throwing a traditional error was not
was I was suggesting although in hindsight my choice of declare name would
indicate exactly that.
What I was suggesting for have a way to tell all functions that throw
Exceptions to simply return instead.
But after further consideration, for that to be useful I realized that such an
approach would require more than just a directive and that is what I emailed
you privately to consider.
> 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.
Ah, good points. Thanks.
Seems like there is a need to be able to say "Don't throw the exception, just
return it to be so I can handle it immediately" but not require a minimum of
five lines of try{}catch{} construct, especially if in this special case
generating the call stack was omitted because it would clearly not be needed...?
-Mike
