Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122315
MIME-Version: 1.0
References: <CAK=iT=UrMCPw5ydCnxa_87ws6xKRO5Y3qJnmchczgDds8u660A@mail.gmail.com>
 <CABigaAUjSx3-vEaQhPk-toJTSg+J3CLrO3otpm1g6hqbYyQKvw@mail.gmail.com>
 <CAK=iT=WgsEZjyu3Y2wTWvycqCsYH7MrLsZgERZK3u75U08ePpA@mail.gmail.com>
 <CAL0xaBHfEMs1BVAMZOuFCUpb9orNSRD0YDhu=3wJAGK7K0_=dg@mail.gmail.com>
 <CAK=iT=XDVcs+y4XDmGu2re137i2yD9LiEj1-HLvyxxxrb8jFUw@mail.gmail.com>
 <CAK=iT=UDUjCZ-25k_MkHFO7uKdWAqoJxdWLVBGM2_SYDk-JyAg@mail.gmail.com>
 <742f202d-7990-4f51-b903-7a15e3fd33c2@app.fastmail.com> <CAL0xaBFybT7F1J5fMZyz9JkeP79iVveCeFTRUFKzQgdgAPDYPQ@mail.gmail.com>
 <fd672e0b-36d9-41da-abd5-623e4018fb0c@app.fastmail.com>
In-Reply-To: <fd672e0b-36d9-41da-abd5-623e4018fb0c@app.fastmail.com>
Date: Tue, 6 Feb 2024 22:15:00 +0200
Message-ID: <CAL0xaBH3VWvgVPW2Uon+mcRfJL1VzWrqAd8MJ5sroOD+miRXfw@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d2a43d0610bc3deb"
Subject: Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--000000000000d2a43d0610bc3deb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 6 Feb 2024 at 22:09, Larry Garfield <larry@garfieldtech.com> wrote:

> On Tue, Feb 6, 2024, at 7:18 PM, Arvids Godjuks wrote:
>
> >> To be clear: I really like this concept and have discussed it with
> others
> >> before, using almost exactly this syntax.  I have not proposed it
> because
> >> my read of Internals lately is that there's no stomach for more
> >> type-centric behavior, especially with the obvious "But we already hav=
e
> >> exceptions, what's yer problem?" response (which is valid to a point,
> but
> >> also incomplete for reasons explained above).  The responses in this
> thread
> >> so far confirm that fear, but as an optimist I'd be very happy to be
> proven
> >> wrong if there is an appetite for improving error handling via the typ=
e
> >> system.
> >>
> >> Absent that, union types and enums (or really any interfaced object) o=
r
> a
> >> purpose-built Either object are the best options today, and while
> they're
> >> not ideal, they're not bad options either.
> >>
> >> None of that logic or argument requires sh*tting on OOP as a concept o=
r
> >> abusing others on the list, however.  Doing that only undermines the
> valid
> >> point that there is ample headroom to improve PHP's error handling.
> >>
> >> --Larry Garfield
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: https://www.php.net/unsub.php
> >>
> >>
> > Thank you Larry for this interesting summary - didn't remember there wa=
s
> > quite a bit a discussion around the topic prior.
> >
> > I lean on the "we have exceptions, just leave it be" side out of
> practical
> > reasons - the vast majority of OO code has standardized around the
> approach
> > and interoperability is high. It makes using code that's out there supe=
r
> > easy and predictable - almost nobody uses the "return false|0|-1" out
> there
> > (at least I haven't used code like that except the PHP's stdlib, and ev=
en
> > that has been changing little by little). It makes error handling
> > predictable, and considering the type of code we mostly write in PHP -
> most
> > of the time we leave the catching to the global top-level handler or
> > sentry/bugsnag/etc libraries.
> > Consistency is the word I want to highlight here. For better or for
> worse -
> > it's the method the PHP ecosystem arrived at and it's the predominant
> one.
> > Introducing a distinctly different method of error handling is going to
> > bring in wrappers around libraries that convert errors to one style or
> the
> > other, the application code can end up using different ways of error
> > handling, etc, etc. My approach is to grab a different language aka "th=
e
> > right tool for the job" if I want to build things differently, that's w=
hy
> > we have so many programming languages and not just a few :)
> >
> > I'd put resources into optimising the VM and php engine to handle the
> > exceptions better and if there are improvements to be had there - do
> those
> > maybe? (I suspect JIT is also going to influence this a lot going
> forward).
>
>
> "The right tool for the job" is indeed the strongest argument for
> lightweight exceptions.  It's a tool we lack right now.
>
> I'm thinking not of "DB went away" type issues (Exceptions are already
> fine there), but "requested product not found."  Right now, the options w=
e
> have are:
>
> public function find($id): ?Product {}
>
> public function find($id): Product {
>     // This is very expensive I don't think will ever not be.
>     // It will also bubble up to the top of the application and crash the
> whole process,
>     // Or still show up in weird, unexpected places.
>     throw new NotFound();
> }
>
> public function find($id): Product|RepoError {}
> enum RepoError {
>     case NotFound;
> }
>
> The first is probably most common, but null (as I go into in the article)
> doesn't tell you anything and leads to mismatch errors.
>
> Exceptions, I'd argue, are just plain wrong in this situation.  (Which
> means, yes, all the frameworks that throw exceptions on route-not-found a=
re
> doing it wrong.)
>
> And the union-enum approach is a bit clunky as it has no native language
> support, and no solid conventions behind it.  This is my preferred approa=
ch
> personally today, but I think we can do better.  Even just having this
> available at all means that "well everyone just uses unchecked exceptions=
"
> isn't entirely true.  (All three of the above can be found in the wild.)
>
> --Larry Garfield
>

And that, folks, is how you change people's minds.

I'm on board, Larry. I agree that things like route not found, entity not
found and so on don't have to be full-fat exceptions - in those cases, you
indeed don't need the stack trace and other parts of it. Even the error
message might not be required since whatever you "throw" or "raise" in this
case is self-explanatory just by its type/object/enum type.

--=20

Arv=C4=ABds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius

--000000000000d2a43d0610bc3deb--