Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122314
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-144-ge5821d614e-fm-20240125.002-ge5821d61
MIME-Version: 1.0
Message-ID: <fd672e0b-36d9-41da-abd5-623e4018fb0c@app.fastmail.com>
In-Reply-To: 
 <CAL0xaBFybT7F1J5fMZyz9JkeP79iVveCeFTRUFKzQgdgAPDYPQ@mail.gmail.com>
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>
Date: Tue, 06 Feb 2024 20:08:51 +0000
To: "Arvids Godjuks" <arvids.godjuks@gmail.com>
Cc: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301
From: larry@garfieldtech.com ("Larry Garfield")

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 have
>> 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 type
>> system.
>>
>> Absent that, union types and enums (or really any interfaced object) or 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 or
>> 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 was
> 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 super
> 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 even
> 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 "the
> right tool for the job" if I want to build things differently, that's why
> 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 we 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 are 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 approach 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