Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122305
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-144-ge5821d614e-fm-20240125.002-ge5821d61
MIME-Version: 1.0
Message-ID: <742f202d-7990-4f51-b903-7a15e3fd33c2@app.fastmail.com>
In-Reply-To: 
 <CAK=iT=UDUjCZ-25k_MkHFO7uKdWAqoJxdWLVBGM2_SYDk-JyAg@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>
Date: Tue, 06 Feb 2024 17:12:44 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
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 4:13 PM, =D0=93=D1=80=D0=B8=D0=B3=D0=BE=D1=80=D0=
=B8=D0=B9 Senior PHP / =D0=A0=D0=B0=D0=B7=D1=80=D0=B0=D0=B1=D0=BE=D1=82=D1=
=87=D0=B8=D0=BA Web wrote:
> Btw, i agree about Javascript, but on a low level it produces the most
> clean code, because there's no types and rules. All types moved to
> TypeScript's client side compiler.
>
> JS 15 years ago ACCIDENTALLY created a pipeline. Named it "Promise". We
> spent years after to understand that while (true) and then/catch shoul=
d be
> different patterns.

I assume much of this thread is a language-barrier issue, which is makin=
g it more hostile than it needs to be.  So let me try and expand a bit, =
because I am actually quite sympathetic to the OP's request, though not =
the way it's being made.

First of all, please don't top post.  It is considered rude on this list=
.  GMail makes it a bit annoying to bottom post but it can be done.  Ple=
ase do so.

Second, there's considerable prior art and discussion on the topic of er=
ror handling and exceptions.  In particular, I recommend this excellent =
article by Joe Duffy:

https://joeduffyblog.com/2016/02/07/the-error-model/

And this one from me:

https://peakd.com/hive-168588/@crell/much-ado-about-null

Yes, they're long, but error handling is a topic that requires more than=
 casual thought.

To summarize the articles for the short of time:

* Exceptions in many languages (including PHP) are very expensive. The s=
tack trace is one of the most expensive things PHP does.  This is one of=
 the reasons why exceptions are terrible for flow control.
* Unchecked exceptions (where a function doesn't define what it can thro=
w) are a great way to break your application in exciting and unpredictab=
le ways.  (This is the other reason exceptions are terrible for flow con=
trol.)
* Many people find checked exceptions cumbersome, even though they are b=
etter (for reasons Duffy goes into).  This is due mostly to bad design o=
f checked exceptions in JVM languages.
* The real problem is that we have a channel for a success case (return =
value), a channel for catastrophic failure (exceptions), but no channel =
for mundane errors (things a responsible developer should expect and kno=
w how to handle gracefully).  So those get shoved into one or the other,=
 usually an exception.

The need is for a "mundane error" channel.  I agree with this.  Differen=
t languages handle it in different ways.

* Go has multi-returns.
* Rust has the Result type (which is an Either monad), and an auto-propa=
gation operator (?).
* PHP has union types (though that's not a deliberate design, just an em=
ergent one).

One of the key differences between different approaches is whether they =
force you to handle error cases (Result type) or let you ignore errors a=
nd assume a happy path (Go, PHP), letting an unhappy path just explode l=
ater on.  Whether the language should force you to think about unhappy p=
aths is a complex and subjective question that I won't delve into now be=
yond saying that there's valid arguments and use cases for both designs.

As noted in the article above, I've started using enums and union type r=
eturns a lot for error handling and it's pretty nice, all things conside=
red.  That works today in all supported PHP verisons (8.1+).  That said,=
 it's not perfect, in part because it's not standardized and there's no =
really good language-level automation around it.

If we had generics and ADTs, building a Rust-like Result type would be s=
uper easy, and I'd suggest we include one in the stdlib for consistency.=
  We'll probably get ADTs eventually, but generics are not something I'd=
 bank on, so that is out.

HOWEVER, and this is where the important part lies, an open, lightweight=
, checked exception system is isomorphic to a Result object.  It's just =
unwrapped.  Compare these hypotheticals:

class DivByZero {}
(this could also be an enum case, but being generic for now.)

function divide(float $a, float $b): Result<int, DivByZero>
{
    if ($b =3D=3D=3D 0) return new Result::Err(new DivByZero());
   return new Result::OK($a/$b);
}

$result =3D divide(5, 0);
$x =3D match ($result) {
  is Result::OK($x) =3D> $x,
  is Result::Err =3D> // Do some kind of error handling.
}

vs.

function divide(float $a, float $b): int raises DivByZero
{
    if ($b =3D=3D=3D 0) raise new DivByZero();
   return new $a/$b;
}

try {
  $result =3D divide(5, 0);
  // Do stuff with $result, knowing it is valid.
} catch (DivByZero) {
  // Do some kind of error handling.
}

These two samples *are logically identical*, and even have mostly the sa=
me performance characteristics, and both expose useful data to static an=
alyzers.  They're just spelled differently.  The advantage of the second=
 is that it could be implemented without generics.  (ADTs would be an op=
tional nice-to-have.)  And if the caller doesn't handle DivByZero, it wo=
uld try to pass it up to its caller, but being checked it would require =
the caller to also declare that it can raise DivByZero.

The second option could also be improved by other syntactic sugar to mak=
e it easier to work with, like Rust has.  For example:

try $result =3D divide(5, 0) catch (DivByZero) { // Error handling that =
evaluates to a value }

Or by making null-aware operators (??, ?->, etc.) treat raised light-exc=
eptions as if they were null to make pipelining easier.  Or various othe=
r ideas I'm just giving examples of for the moment to make the point, bu=
t let's not get off on that tangent.  (I would also note that I agree en=
tirely such a system should only support objects, not primitives.)

This would provide a far better alternative to the "returns value on suc=
cess or false on failure" anti-pattern throughout the stdlib, and to the=
 common "returns value on success or null on failure or value not found =
or any other possible issue" pattern common in user-space code.  (No, I =
don't expect us to go back and change all of stdlib; just pointing out t=
hat it's a known language limitation, and this would be the solution.)

To be clear: I really like this concept and have discussed it with other=
s before, using almost exactly this syntax.  I have not proposed it beca=
use my read of Internals lately is that there's no stomach for more type=
-centric behavior, especially with the obvious "But we already have exce=
ptions, what's yer problem?" response (which is valid to a point, but al=
so incomplete for reasons explained above).  The responses in this threa=
d so far confirm that fear, but as an optimist I'd be very happy to be p=
roven 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 val=
id point that there is ample headroom to improve PHP's error handling.

--Larry Garfield