Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127225
Precedence: bulk
MIME-Version: 1.0
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>
In-Reply-To: <150fb4df-47a4-4ab3-8edb-13e446b122cc@app.fastmail.com>
Date: Mon, 28 Apr 2025 19:28:09 +0300
Message-ID: <CAMW7n8DX9oakMgJ0he_67OTrnTKUFzwg-fsE-thP9f2xcg=VXw@mail.gmail.com>
Subject: Re: [PHP-DEV] Concept: Lightweight error channels
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000012945b0633d92c9b"
From: edmond.ht@gmail.com (Edmond Dantes)

--00000000000012945b0633d92c9b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>  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 error
channels*.
This is harder to understand than the Normal returns + Exception channels +
Something new.

It seems to me that this creates a bigger problem than the one it is trying
to solve.

Is it possible to avoid creating two error channels and instead design an
alternative handling method that would eliminate the drawbacks of the first
approach?

If the performance issue is solved, are the other two problems really worth
such changes?

For example, if we follow the philosophy of RESULT<X>, we can say that
there are two types of exception handling cases:

   1.

   Suppressing an exception immediately at the first level of function call=
.
   2.

   Stack unwinding.

For example, the expression:


```php

function someFunction(): string raises  SomeException   {

    throw  SomeException()
}

//  The backtrace is not generated:

$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 time, i=
t allows
improving PHP performance and adding contracts.

--00000000000012945b0633d92c9b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;=C2=A0 I have already demonstrated how it can be solve=
d without generics.=C2=A0 Multiple response channels from a function alread=
y exist: Normal returns and exceptions.=C2=A0 Exceptions as currently desig=
ned are just very poorly suited to the problem space I am describing.<div><=
br></div><div>If another error channel is introduced, PHP would end up with=
 <b>two error channels</b>.<br>
This is harder to understand than the Normal returns + Exception channels +=
 Something new.=C2=A0=C2=A0</div><div><br></div><div>It seems to me that th=
is creates a bigger problem than the one it is trying to solve.=C2=A0=C2=A0=
</div><div><br></div><div>Is it possible to avoid creating two error channe=
ls and instead design an alternative handling method that would eliminate t=
he drawbacks of the first approach?=C2=A0=C2=A0</div><div><br></div><div>If=
 the performance issue is solved, are the other two problems really worth s=
uch changes?=C2=A0=C2=A0</div><div><br></div><div>For example, if we follow=
 the philosophy of <code>RESULT&lt;X&gt;</code>, we can say that there are =
two types of exception handling cases:</div><div>
<ol>
<li class=3D"gmail-">
<p class=3D"gmail-">Suppressing an exception immediately at the first level=
 of function call.</p>
</li>
<li class=3D"gmail-">
<p class=3D"gmail-">Stack unwinding.</p>
</li>
</ol>
<p class=3D"gmail-">For example, the expression:</p><p class=3D"gmail-"><br=
>```php</p><p class=3D"gmail-"><span style=3D"color:rgb(80,0,80)">function =
someFunction(): string=C2=A0</span>raises=C2=A0

<span style=3D"color:rgb(80,0,80)">SomeException</span>=C2=A0=C2=A0<span st=
yle=3D"color:rgb(80,0,80)">=C2=A0</span><span style=3D"color:rgb(80,0,80)">=
{</span></p><p class=3D"gmail-"><span style=3D"color:rgb(80,0,80)">=C2=A0 =
=C2=A0 throw=C2=A0</span>

<span style=3D"color:rgb(80,0,80)">SomeException()</span><span style=3D"col=
or:rgb(80,0,80)"><br></span><span style=3D"color:rgb(80,0,80)">}</span><spa=
n style=3D"color:rgb(80,0,80)"></span></p><p class=3D"gmail-">//=C2=A0

The backtrace is not generated:=C2=A0</p><p class=3D"gmail-"><span style=3D=
"color:rgb(80,0,80)">$res =3D try someFunction() catch (SomeException) null=
;</span></p><p class=3D"gmail-"><span style=3D"color:rgb(80,0,80)">//=C2=A0=
</span>The backtrace is generated when throw=C2=A0$err executed.</p><p clas=
s=3D"gmail-"><span style=3D"color:rgb(80,0,80)">$res =3D try someFunction()=
 catch ($err) {throw $err};</span></p><p class=3D"gmail-"><span style=3D"co=
lor:rgb(80,0,80)">//=C2=A0</span>The backtrace is generated</p><p class=3D"=
gmail-"><span style=3D"color:rgb(80,0,80)">$res =3D someFunction();</span><=
/p><p class=3D"gmail-">```</p><p class=3D"gmail-">This kind of behavior doe=
sn=E2=80=99t break BC, right?=C2=A0

At the same time, it allows improving PHP performance and adding contracts.

</p></div></div>

--00000000000012945b0633d92c9b--