Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127226
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 28 Apr 2025 14:21:35 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <8ba39427-bc2d-4c2a-90d8-648371e4f576@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8DX9oakMgJ0he_67OTrnTKUFzwg-fsE-thP9f2xcg=VXw@mail.gmail.com>
References: <39597a9c-6854-40c6-a529-32b2b178cb27@app.fastmail.com>
 <CAMW7n8CNTwOtsUbAbH-0Kk1Ck3DZ1fKF=P9GfctwDk9KmCr2XQ@mail.gmail.com>
 <ded712fb-b339-4160-8625-0f778a9c3926@app.fastmail.com>
 <CAMW7n8C1B68YU-369vjW1ui2iq1KS+kVE0m=hDdAiHSV-FKhJw@mail.gmail.com>
 <150fb4df-47a4-4ab3-8edb-13e446b122cc@app.fastmail.com>
 <CAMW7n8DX9oakMgJ0he_67OTrnTKUFzwg-fsE-thP9f2xcg=VXw@mail.gmail.com>
Subject: Re: [PHP-DEV] Concept: Lightweight error channels
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Apr 28, 2025, at 11:28 AM, Edmond Dantes wrote:
>>  I have already demonstrated how it can be solved without generics.  =
Multiple response channels from a function already exist: Normal returns=
 and exceptions.  Exceptions as currently designed are just very poorly =
suited to the problem space I am describing.
>
> If another error channel is introduced, PHP would end up with *two=20
> error channels*.
> This is harder to understand than the Normal returns + Exception=20
> channels + Something new. =20
>
> It seems to me that this creates a bigger problem than the one it is=20
> trying to solve. =20
>
> Is it possible to avoid creating two error channels and instead design=20
> an alternative handling method that would eliminate the drawbacks of=20
> the first approach? =20
>
> If the performance issue is solved, are the other two problems really=20
> worth such changes? =20
>
> For example, if we follow the philosophy of `RESULT<X>`, we can say=20
> that there are two types of exception handling cases:
>  1. Suppressing an exception immediately at the first level of functio=
n=20
> call.

Suppressing?  You mean fataling.  Suppressing implies ignore, which is t=
he exact opposite of what I am proposing.

>  2. Stack unwinding.

Given the choice between:

success return + error-return + the-world-is-broken

vs

success return + the-world-is-broken + the-world-is-broken-but-not-reall=
y-so-you-have-to-handle-it

The first seems substantially better, frankly.

Exceptions that are sometimes checked and sometimes not is Java, which i=
s exactly why everyone hates Java's exception system.

> ```php
>
> function someFunction(): string raises  SomeException   {
>
>     throw SomeException()
> }
>
> //  The backtrace is not generated:=20
>
> $res =3D try someFunction() catch (SomeException) null;
>
> // The backtrace is generated when throw $err executed.
>
> $res =3D try someFunction() catch ($err) {throw $err};
>
> // The backtrace is generated
>
> $res =3D someFunction();
>
> ```
>
> This kind of behavior doesn=E2=80=99t break BC, right?  At the same ti=
me, it=20
> allows improving PHP performance and adding contracts.

The particulars there in that syntax imply the only catch handling would=
 be defining a different value, which may not be the desired handling.

Also, that again runs into "throw may be checked or not, you don't alway=
s know."

It also means the exception is carrying around the extra design baggage =
of exceptions.  Even if the trace is elided, it's still carrying useless=
 metadata that would lead people astray.  It also means dealing with the=
 constructor of Exceptions, which is notoriously annoying for extending.

"Make exceptions nicer" is fundamentally not what I am proposing, nor wi=
ll I propose as a solution for this space.  It is the wrong approach.  (=
Making exceptions nicer is well and good in its own right, and I won't b=
lock that, but it does not address this problem space.)

It's clear you do not support what I am proposing.  Good to know, thanks=
.  I still haven't gotten any feedback from major voters, though, so lea=
ving this thread open.

--Larry Garfield