Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127220
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>
In-Reply-To: <ded712fb-b339-4160-8625-0f778a9c3926@app.fastmail.com>
Date: Mon, 28 Apr 2025 14:46:26 +0300
Message-ID: <CAMW7n8C1B68YU-369vjW1ui2iq1KS+kVE0m=hDdAiHSV-FKhJw@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="0000000000008d5b920633d53cc0"
From: edmond.ht@gmail.com (Edmond Dantes)

--0000000000008d5b920633d53cc0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello all.

> Yes.  And even if it can be made faster (as it looks like Niels is doing,
which is great), it will never be as fast as an empty constructor and a
return.  That's the level I'm proposing.

If the backtrace is generated only when needed, rather than at the moment
the exception is created, there will be no difference or almost no
difference (if a stack unwinding algorithm is used).

The total number of CPU/memory operations will be approximately the same.
The only difference is that deferred backtrace generation will require more
complex frame return code, which may introduce pitfalls.
However, if a backtrace is needed by itself, such overhead is unavoidable
regardless of whether exceptions are used or not.

> I somewhat glossed over this point, but let me expand on it here.

So the exception hierarchy in PHP is far from ideal. Understood. The
hierarchy can be improved to make it more logical and consistent. And as I
understand it, changing the exceptions themselves is not required for
that.

> Moreover, all exceptions currently track:

Yes. And the main problem among them is the trace property. Neither file
nor line cause significant overhead, because file is a reference to a
string constant, and line is an integer.

> This is incorrect, as making the current exception system checked would
be a ginormous BC break.
> And having some throwables be checked and some not, but using the same
syntax and class hierarchy... well, that's the reason everyone detests
Java's exceptions.  Let's not do that.

While introducing a new entity, such as a "New Error Stream" with defined
contract rules, is theoretically possible,
it would not fundamentally change the current situation.

In practice, this approach would introduce a second category of exceptions,
requiring developers to manage:

   -

   the primary execution flow,
   -

   the standard exception flow,
   -

   a "special exception flow" that must be converted back into the standard
   one when necessary.

This added complexity may outweigh the potential benefits, especially given
that the primary value would be limited to preserving backward
compatibility.

It is worth carefully considering whether such a change justifies the
additional mental and technical overhead.

On the other side of the scale:


   -

   replacing @throws with a special syntax (or perhaps simply introducing a
   new attribute?),
   -

   defining the behavior in case of contract violation while preserving
   backward compatibility.

For example, if an exception contract is violated, an error would not be
thrown; instead, a warning would be issued, which would not break the
program's execution flow but would help draw the developer=E2=80=99s attent=
ion to
the issue.

Later in the letter you explain in more detail that this is *not a special
kind of exception*, nor a new execution flow, but rather a* special type of
result*.

But if this is a special type of result, then it should follow *the same
rules as all PHP types*.  In other words, this cannot be solved without
generics.

However, the benefit of the new syntax, which could make the code cleaner,
does not depend on generics:
For example:

```php
$res =3D someFunction() catch ($err) {throw $err;} // Like Zig?
```

But then the return type must be Throwable.

The advantage of generics like Result<> is that they do not create a
separate return channel.
Everything operates within a single flow.
However, this approach is not yet possible in PHP.

Introducing an additional return channel would mean increasing the overall
complexity.

Of course, this is a clean and useful syntax for such cases.
Moreover, the catch block could be made mandatory if the function is marked
with a contract =E2=80=94 meaning the function cannot be called without a c=
atch
block at all.

However, it seems to me that we can achieve the same result using throw,
simply by adding new syntax and capabilities.  Yes, there may be some
backward compatibility issues, but is it really something to be afraid of?

--0000000000008d5b920633d53cc0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello all.<div><br></div><div>&gt; Yes.=C2=A0 And even if =
it can be made faster (as it looks like Niels is doing, which is great), it=
 will never be as fast as an empty constructor and a return.=C2=A0 That&#39=
;s the level I&#39;m proposing.</div><div><br></div><div>If the backtrace i=
s generated only when needed, rather than at the moment the exception is cr=
eated, there will be no difference or almost no difference (if a stack unwi=
nding algorithm is used).=C2=A0=C2=A0</div><div><br></div><div>The total nu=
mber of CPU/memory operations will be approximately the same. The only diff=
erence is that deferred backtrace generation will require more complex fram=
e return code, which may introduce pitfalls.<br>
However, if a backtrace is needed by itself, such overhead is unavoidable r=
egardless of whether exceptions are used or not.=C2=A0=C2=A0</div><div><br>=
</div><div>&gt; I somewhat glossed over this point, but let me expand on it=
 here.<br><br>So the exception hierarchy in PHP is far from ideal. Understo=
od. The hierarchy can be improved to make it more logical and consistent. A=
nd as I understand it, changing the exceptions themselves is not required f=
or that.=C2=A0=C2=A0</div><div><br></div><div>&gt; Moreover, all exceptions=
 currently track:<br><br>Yes. And the main problem among them is the <code>=
trace</code> property. Neither <code>file</code> nor <code>line</code> caus=
e significant overhead, because <code>file</code> is a reference to a strin=
g constant, and <code>line</code> is an integer.</div><div><br></div><div>&=
gt; This is incorrect, as making the current exception system checked would=
 be a ginormous BC break.=C2=A0 <br>&gt; And having some throwables be chec=
ked and some not, but using the same syntax and class hierarchy... well, th=
at&#39;s the reason everyone detests Java&#39;s exceptions.=C2=A0 Let&#39;s=
 not do that.<br><p class=3D"gmail-">While introducing a new entity, such a=
s a &quot;New Error Stream&quot; with defined contract rules, is theoretica=
lly possible,<br>
it would not fundamentally change the current situation.</p>
<p class=3D"gmail-">In practice, this approach would introduce a second cat=
egory of exceptions, requiring developers to manage:</p>
<ul>
<li class=3D"gmail-">
<p class=3D"gmail-">the primary execution flow,</p>
</li>
<li class=3D"gmail-">
<p class=3D"gmail-">the standard exception flow,</p>
</li>
<li class=3D"gmail-">
<p class=3D"gmail-">a &quot;special exception flow&quot; that must be conve=
rted back into the standard one when necessary.</p>
</li>
</ul>
<p class=3D"gmail-">This added complexity may outweigh the potential benefi=
ts, especially given that the primary value would be limited to preserving =
backward compatibility.=C2=A0</p><p class=3D"gmail-">It is worth carefully =
considering whether such a change justifies the additional mental and techn=
ical overhead.</p><p class=3D"gmail-">On the other side of the scale:</p><p=
 class=3D"gmail-">
</p><ul>
<li class=3D"gmail-">
<p class=3D"gmail-">replacing <code>@throws</code> with a special syntax (o=
r perhaps simply introducing a new attribute?),</p>
</li>
<li class=3D"gmail-">
<p class=3D"gmail-">defining the behavior in case of contract violation whi=
le preserving backward compatibility.</p></li></ul><div>For example, if an =
exception contract is violated, an error would not be thrown; instead, a wa=
rning would be issued, which would not break the program&#39;s execution fl=
ow but would help draw the developer=E2=80=99s attention to the issue.</div=
></div><div><br></div><div>Later in the letter you explain in more detail t=
hat this is <b>not a special kind of exception</b>, nor a new execution flo=
w, but rather a<b> special type of result</b>.=C2=A0=C2=A0</div><div><br></=
div><div>But if this is a special type of result, then it should follow <b>=
the same rules as all PHP types</b>.=C2=A0

In other words, this cannot be solved without generics.

<br><br></div><div>However, the benefit of the new syntax, which could make=
 the code cleaner, does not depend on generics:=C2=A0=C2=A0</div><div>For e=
xample:=C2=A0=C2=A0</div><div><br></div><div>```php=C2=A0<br>$res =3D someF=
unction() catch ($err) {throw $err;} // Like Zig? <br>```<br></div><div><br=
></div><div>But then the return type must be <code>Throwable</code>.=C2=A0=
=C2=A0</div><div><p class=3D"gmail-">The advantage of generics like <code>R=
esult&lt;&gt;</code> is that they do not create a separate return channel.<=
br>
Everything operates within a single flow.<br>
However, this approach is not yet possible in PHP.</p>
<p class=3D"gmail-">Introducing an additional return channel would mean inc=
reasing the overall complexity.</p></div><div><p class=3D"gmail-">Of course=
, this is a clean and useful syntax for such cases.<br>
Moreover, the <code>catch</code> block could be made mandatory if the funct=
ion is marked with a contract =E2=80=94 meaning the function cannot be call=
ed without a <code>catch</code> block at all.</p>
<p class=3D"gmail-">However, it seems to me that we can achieve the same re=
sult using <code>throw</code>, simply by adding new syntax and capabilities=
.=C2=A0

Yes, there may be some backward compatibility issues, but is it really some=
thing to be afraid of?

</p></div></div>

--0000000000008d5b920633d53cc0--