Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127189
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 26 Apr 2025 18:19:19 +0200
To: internals@lists.php.net
Message-ID: <7e923206-139a-4442-824e-895b09d563a2@app.fastmail.com>
In-Reply-To: <39597a9c-6854-40c6-a529-32b2b178cb27@app.fastmail.com>
References: <39597a9c-6854-40c6-a529-32b2b178cb27@app.fastmail.com>
Subject: Re: [PHP-DEV] Concept: Lightweight error channels
Content-Type: multipart/alternative;
 boundary=e8ba629ad24c4abe9a86fffb851d303b
From: rob@bottled.codes ("Rob Landers")

--e8ba629ad24c4abe9a86fffb851d303b
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Sat, Apr 26, 2025, at 09:17, Larry Garfield wrote:
> Hi folks.  In several recent RFCs and related discussion, the question=
 of error handling has come up.  Specifically, the problem is:
>=20
> * "return null" conflicts with "but sometimes null is a real value" (t=
he validity of that position is debatable, but common), and provides no =
useful information as to what went wrong.
> * Exceptions are very expensive, the hierarchy is confusing, and handl=
ing them properly is a major pain.  Failing to handle them properly is v=
ery easy since you have no way of knowing what exceptions the code you'r=
e calling might throw, or its nested calls, etc.  That makes them poorly=
 suited for mundane, predictable error conditions.
> * trigger_error() is, well, a mess and not suitable for signaling to a=
 calling function that something recoverable-in-context went wrong.
> * And... that's all we've got as options.
>=20
> I've had an idea kicking around in my head for a while, which I know I=
've mentioned before.  Given the timing, I want to put it out in its cur=
rent unfinished form to see if there's interest in me bothering to finis=
h it, or if it doesn't have a snowball's chance in hell of happening so =
it's not worth my time to further develop.
>=20
> I know I've posted this before, but it's useful for background:
>=20
> https://peakd.com/hive-168588/@crell/much-ado-about-null
> https://joeduffyblog.com/2016/02/07/the-error-model/
>=20
> From both prior discussions here as well as my understanding of langua=
ge design trends, it seems the consensus view is that a Result type (aka=
, an Either monad) is the ideal mechanism for robust error handling.  Ho=
wever, it requires generics to be really viable, which we don't have.  I=
t's also very clumsy to use in a classic-OOP language (like PHP) without=
 special dedicated syntax.
>=20
> Various languages work around that in various ways.  Rust built its wh=
ole error system on Result types, and later added the `?` operator to in=
dicate "and if this returns an error result, just return it directly", m=
aking delegating error handling vastly easier.  Kotlin (via its Arrow li=
brary) relies on heavy use of chained tail-closures.  Go has a conventio=
n of a "naked either" using two return values, but doesn't have any spec=
ial syntax for it leading to famously annoying boilerplate.  Python has =
lightweight exceptions so that throwing them willy nilly as a control fl=
ow tool is actually OK and Pythonic.
>=20
> However, as noted in the "Error Model" article above, and this is key,=
 a Result type is isomorphic to a *checked* exception.  A checked except=
ion is one where a function must explicitly declare what it can throw, a=
nd if it throws something else it's the function's error, and a compile =
time error.  It also means any "bubbling" of exceptions has to be explic=
it at each function step.  That's in contrast to unchecked exceptions, a=
s PHP has now, which may be thrown from nearly anywhere and will silentl=
y bubble up and crash the program if not otherwise handled.
>=20
> The key point here is that a happy-path return and an unhappy-but-not-=
world-ending-path need to be different.  Using the return value for both=
 (what returning null does) is simply insufficient. =20
>=20
> The "Error Model" article goes into the pros and cons of checked vs un=
checked exceptions so I won't belabor the point, except to say that most=
 arguments against checked exceptions are based on Java's very-broken im=
plementation of checked-except-when-it's-not exceptions.  But as noted, =
what Rust and Go do is checked exceptions, aka a Result type, just spell=
ed differently.  The advantage of checked exceptions is that we don't ne=
ed generics at all, and still get all the benefits.  We can also design =
syntax around them specifically to make them more ergonomic.
>=20
> I am invisioning something like this:
>=20
> ```
> function div(int $n, int $d): float raises ZeroDivisor
> {
>   if ($d =3D=3D=3D 0) {
>     raise new ZeroDivisor();  // This terminates the function.
>   }
>   return $n/$d;
> }
> ```
>=20
> The "raises" declaration specifies a class or interface type that coul=
d be "raised".  It can be any object; no required Exception hierarchy, n=
o backtrace, just a boring old object value.  Enum if you feel like it, =
or any other object.  We could probably allow union or full DNF types th=
ere if we wanted, though I worry that it may lead to too confusing of an=
 API. (To bikeshed later.)  Static analysis tools could very easily dete=
ct if the code doesn't match up with the declared raises.
>=20
> This feature already exists in both Midori (the subject of the "Error =
Model" article) and Swift.  So it's not a new invention; in fact it's qu=
ite old.
>=20
> The handling side is where I am still undecided on syntax.  Swift uses=
 essentially try-catch blocks, though I fear that would be too verbose i=
n practice and would be confused with existing "heavy" exceptions.  Mido=
ri did the same. =20
>=20
> Various ideas I've pondered in no particular order:
>=20
> ```
> // Suck it up and reuse try-catch
>=20
> function test() { // No declared raise, so if it doesn't handle ZeroDi=
visor itself, fatal.
>   try {
>     $val =3D div(3, 0);
>   } catch (ZeroDivisor $e) {
>     print "Nope.";
>   }
> }
> ```
>=20
> ```
> // try-catch spelled differently to avoid confusion with exceptions
> try {
>   $val =3D div(3, 0);
> } handle (ZeroDivisor $e) {
>   print "Nope.";
> }
> ```
>=20
> ```
> // Some kind of suffix block, maybe with a specially named variable?
>=20
> $val =3D div(3, 0) else { print $err->message; return 0; }
> ```
>=20
> ```
> // A "collapsed" try-catch block.
> $val =3D try div(3, 0)=20
>   catch (ZeroDivisor $e) { print "Nope"; }
>   catch (SomethingElse $e) { print "Wat?"; }
> ```
>=20
> ```
> // Similar to Rust's ? operator, to make propagating an error easier.
>=20
> // The raise here could be the same or wider than what div() raises.
> function test(): float raises ZeroDivisor {
>   $val =3D div(3, 0) reraise;
>   // use $val safely knowing it was returned and nothing was raised.
> }
> ```
>=20
> Or other possibilities I've not considered.
>=20
> The use cases for a dedicated error channel are many:
>=20
> * Any variation of "out of bounds": Could be "record not found in data=
base", or "no such array key" or "you tried to get the first item of an =
empty list", or many other things along those lines.
> * Expected input validation errors.  This would cover the URL/URI RFC'=
s complex error messages, without the C-style "inout" parameter.
> * Chaining validation.  A series of validators that can return true (o=
r just the value being validated) OR raise an object with the failure re=
ason.  A wrapping function can collect them all into a single error obje=
ct to return to indicate all the various validation failures.
> * A transformer chain, which does the same as validation but passes on=
 the transformed value and raises on the first erroring transformer.
>=20
> Exceptions remain as is, for "stop the world" unexpected failures or d=
eveloper errors (bugs).  But mundane errors, where local resolution is b=
oth possible and appropriate, get a dedicated channel and syntax with no=
 performance overhead.  That also naturally becomes a Python-style "bett=
er to beg forgiveness than ask permission" approach to error handling if=
 desired, without all the overhead of exceptions.
>=20
>=20
> So that's what I've got so far.  My question for the audience is:
>=20
> 1. Assuming we could flesh out a comfortable and ergonomic syntax, wou=
ld you support this feature, or would you reject it out of hand?
>=20
> 2. For engine-devs: Is this even feasible? :-)  And if so, anyone want=
 to join me in developing it?
>=20
> 3. And least relevant, I'm very open to suggestions for the syntax, th=
ough the main focus right now is question 1 to determine if discussing s=
yntax is even worthwhile.
>=20
>=20
> --=20
>   Larry Garfield
>   larry@garfieldtech.com
>=20

Hey Larry,

I=E2=80=99m still digesting this, but I wonder if this problem (errors v=
s non-world-ending errors vs happy path) is a problem due to people ofte=
n making warnings into exceptions?

I feel like many devs/frameworks =E2=80=9Cabuse=E2=80=9D (for lack of a =
better word) the error handling system to make everything into a world-e=
nding-error when it is not.=20

Even over the last few versions of PHP, more and more warnings have turn=
ed into exceptions that maybe ought not be.

Overall, this has resulted in a somewhat more inconsistent language than=
 it was previously. For example, you used to be able to consider an arra=
y as a field of infinite nulls. You could iterate over an infinite set o=
f keys and get nothing but null. This made it easier to explain to junio=
r devs at the time. Now, you have to explain it as a hash-map-but-someti=
mes-array-thing that emits warnings when a key doesn=E2=80=99t exist but=
 will still give you null.=20

We are currently in this weird place between =E2=80=9Cinfinite field of =
nulls=E2=80=9D and =E2=80=9Csparse array/hash-map=E2=80=9D but not quite=
 either one =E2=80=94 depending on what you do with that warning.=20

It would be great if we could pick one and I think it would also solve t=
he whole =E2=80=9Cis null an error or a value=E2=80=9D problem.=20

I personally wouldn=E2=80=99t like checked exceptions. I have PTSD from =
Java=E2=80=99s, so just hearing that phrase gives me flashbacks of catch=
ing dozens of potential exceptions. In Go, yes there is some boilerplate=
, but it=E2=80=99s not that bad and it easy to deal with, especially wit=
h IDE support.=20

As for a Result type, that=E2=80=99s already possible in user-land; what=
 does bringing it to the engine get us? Is it just a lightweight excepti=
on without a trace to prevent the cost of generation? Why not just have =
a pool of exceptions that you can just modify the message?

=E2=80=94 Rob
--e8ba629ad24c4abe9a86fffb851d303b
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Sat, Apr 26, 2025, at 09:17, Larry Garfield wrote:<=
/div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>Hi folks.&nbsp;=
 In several recent RFCs and related discussion, the question of error ha=
ndling has come up.&nbsp; Specifically, the problem is:</div><div><br></=
div><div>* "return null" conflicts with "but sometimes null is a real va=
lue" (the validity of that position is debatable, but common), and provi=
des no useful information as to what went wrong.</div><div>* Exceptions =
are very expensive, the hierarchy is confusing, and handling them proper=
ly is a major pain.&nbsp; Failing to handle them properly is very easy s=
ince you have no way of knowing what exceptions the code you're calling =
might throw, or its nested calls, etc.&nbsp; That makes them poorly suit=
ed for mundane, predictable error conditions.</div><div>* trigger_error(=
) is, well, a mess and not suitable for signaling to a calling function =
that something recoverable-in-context went wrong.</div><div>* And... tha=
t's all we've got as options.</div><div><br></div><div>I've had an idea =
kicking around in my head for a while, which I know I've mentioned befor=
e.&nbsp; Given the timing, I want to put it out in its current unfinishe=
d form to see if there's interest in me bothering to finish it, or if it=
 doesn't have a snowball's chance in hell of happening so it's not worth=
 my time to further develop.</div><div><br></div><div>I know I've posted=
 this before, but it's useful for background:</div><div><br></div><div><=
a href=3D"https://peakd.com/hive-168588/@crell/much-ado-about-null">http=
s://peakd.com/hive-168588/@crell/much-ado-about-null</a></div><div><a hr=
ef=3D"https://joeduffyblog.com/2016/02/07/the-error-model/">https://joed=
uffyblog.com/2016/02/07/the-error-model/</a></div><div><br></div><div>Fr=
om both prior discussions here as well as my understanding of language d=
esign trends, it seems the consensus view is that a Result type (aka, an=
 Either monad) is the ideal mechanism for robust error handling.&nbsp; H=
owever, it requires generics to be really viable, which we don't have.&n=
bsp; It's also very clumsy to use in a classic-OOP language (like PHP) w=
ithout special dedicated syntax.</div><div><br></div><div>Various langua=
ges work around that in various ways.&nbsp; Rust built its whole error s=
ystem on Result types, and later added the `?` operator to indicate "and=
 if this returns an error result, just return it directly", making deleg=
ating error handling vastly easier.&nbsp; Kotlin (via its Arrow library)=
 relies on heavy use of chained tail-closures.&nbsp; Go has a convention=
 of a "naked either" using two return values, but doesn't have any speci=
al syntax for it leading to famously annoying boilerplate.&nbsp; Python =
has lightweight exceptions so that throwing them willy nilly as a contro=
l flow tool is actually OK and Pythonic.</div><div><br></div><div>Howeve=
r, as noted in the "Error Model" article above, and this is key, a Resul=
t type is isomorphic to a *checked* exception.&nbsp; A checked exception=
 is one where a function must explicitly declare what it can throw, and =
if it throws something else it's the function's error, and a compile tim=
e error.&nbsp; It also means any "bubbling" of exceptions has to be expl=
icit at each function step.&nbsp; That's in contrast to unchecked except=
ions, as PHP has now, which may be thrown from nearly anywhere and will =
silently bubble up and crash the program if not otherwise handled.</div>=
<div><br></div><div>The key point here is that a happy-path return and a=
n unhappy-but-not-world-ending-path need to be different.&nbsp; Using th=
e return value for both (what returning null does) is simply insufficien=
t.&nbsp;&nbsp;</div><div><br></div><div>The "Error Model" article goes i=
nto the pros and cons of checked vs unchecked exceptions so I won't bela=
bor the point, except to say that most arguments against checked excepti=
ons are based on Java's very-broken implementation of checked-except-whe=
n-it's-not exceptions.&nbsp; But as noted, what Rust and Go do is checke=
d exceptions, aka a Result type, just spelled differently.&nbsp; The adv=
antage of checked exceptions is that we don't need generics at all, and =
still get all the benefits.&nbsp; We can also design syntax around them =
specifically to make them more ergonomic.</div><div><br></div><div>I am =
invisioning something like this:</div><div><br></div><div>```</div><div>=
function div(int $n, int $d): float raises ZeroDivisor</div><div>{</div>=
<div>&nbsp; if ($d =3D=3D=3D 0) {</div><div>&nbsp;&nbsp;&nbsp; raise new=
 ZeroDivisor();&nbsp; // This terminates the function.</div><div>&nbsp; =
}</div><div>&nbsp; return $n/$d;</div><div>}</div><div>```</div><div><br=
></div><div>The "raises" declaration specifies a class or interface type=
 that could be "raised".&nbsp; It can be any object; no required Excepti=
on hierarchy, no backtrace, just a boring old object value.&nbsp; Enum i=
f you feel like it, or any other object.&nbsp; We could probably allow u=
nion or full DNF types there if we wanted, though I worry that it may le=
ad to too confusing of an API. (To bikeshed later.)&nbsp; Static analysi=
s tools could very easily detect if the code doesn't match up with the d=
eclared raises.</div><div><br></div><div>This feature already exists in =
both Midori (the subject of the "Error Model" article) and Swift.&nbsp; =
So it's not a new invention; in fact it's quite old.</div><div><br></div=
><div>The handling side is where I am still undecided on syntax.&nbsp; S=
wift uses essentially try-catch blocks, though I fear that would be too =
verbose in practice and would be confused with existing "heavy" exceptio=
ns.&nbsp; Midori did the same.&nbsp;&nbsp;</div><div><br></div><div>Vari=
ous ideas I've pondered in no particular order:</div><div><br></div><div=
>```</div><div>// Suck it up and reuse try-catch</div><div><br></div><di=
v>function test() { // No declared raise, so if it doesn't handle ZeroDi=
visor itself, fatal.</div><div>&nbsp; try {</div><div>&nbsp;&nbsp;&nbsp;=
 $val =3D div(3, 0);</div><div>&nbsp; } catch (ZeroDivisor $e) {</div><d=
iv>&nbsp;&nbsp;&nbsp; print "Nope.";</div><div>&nbsp; }</div><div>}</div=
><div>```</div><div><br></div><div>```</div><div>// try-catch spelled di=
fferently to avoid confusion with exceptions</div><div>try {</div><div>&=
nbsp; $val =3D div(3, 0);</div><div>} handle (ZeroDivisor $e) {</div><di=
v>&nbsp; print "Nope.";</div><div>}</div><div>```</div><div><br></div><d=
iv>```</div><div>// Some kind of suffix block, maybe with a specially na=
med variable?</div><div><br></div><div>$val =3D div(3, 0) else { print $=
err-&gt;message; return 0; }</div><div>```</div><div><br></div><div>```<=
/div><div>// A "collapsed" try-catch block.</div><div>$val =3D try div(3=
, 0)&nbsp;</div><div>&nbsp; catch (ZeroDivisor $e) { print "Nope"; }</di=
v><div>&nbsp; catch (SomethingElse $e) { print "Wat?"; }</div><div>```</=
div><div><br></div><div>```</div><div>// Similar to Rust's ? operator, t=
o make propagating an error easier.</div><div><br></div><div>// The rais=
e here could be the same or wider than what div() raises.</div><div>func=
tion test(): float raises ZeroDivisor {</div><div>&nbsp; $val =3D div(3,=
 0) reraise;</div><div>&nbsp; // use $val safely knowing it was returned=
 and nothing was raised.</div><div>}</div><div>```</div><div><br></div><=
div>Or other possibilities I've not considered.</div><div><br></div><div=
>The use cases for a dedicated error channel are many:</div><div><br></d=
iv><div>* Any variation of "out of bounds": Could be "record not found i=
n database", or "no such array key" or "you tried to get the first item =
of an empty list", or many other things along those lines.</div><div>* E=
xpected input validation errors.&nbsp; This would cover the URL/URI RFC'=
s complex error messages, without the C-style "inout" parameter.</div><d=
iv>* Chaining validation.&nbsp; A series of validators that can return t=
rue (or just the value being validated) OR raise an object with the fail=
ure reason.&nbsp; A wrapping function can collect them all into a single=
 error object to return to indicate all the various validation failures.=
</div><div>* A transformer chain, which does the same as validation but =
passes on the transformed value and raises on the first erroring transfo=
rmer.</div><div><br></div><div>Exceptions remain as is, for "stop the wo=
rld" unexpected failures or developer errors (bugs).&nbsp; But mundane e=
rrors, where local resolution is both possible and appropriate, get a de=
dicated channel and syntax with no performance overhead.&nbsp; That also=
 naturally becomes a Python-style "better to beg forgiveness than ask pe=
rmission" approach to error handling if desired, without all the overhea=
d of exceptions.</div><div><br></div><div><br></div><div>So that's what =
I've got so far.&nbsp; My question for the audience is:</div><div><br></=
div><div>1. Assuming we could flesh out a comfortable and ergonomic synt=
ax, would you support this feature, or would you reject it out of hand?<=
/div><div><br></div><div>2. For engine-devs: Is this even feasible? :-)&=
nbsp; And if so, anyone want to join me in developing it?</div><div><br>=
</div><div>3. And least relevant, I'm very open to suggestions for the s=
yntax, though the main focus right now is question 1 to determine if dis=
cussing syntax is even worthwhile.</div><div><br></div><div><br></div><d=
iv>--&nbsp;</div><div>&nbsp; Larry Garfield</div><div>&nbsp;&nbsp;<a hre=
f=3D"mailto:larry@garfieldtech.com">larry@garfieldtech.com</a></div><div=
><br></div></blockquote><div><br></div><div>Hey Larry,</div><div><br></d=
iv><div>I=E2=80=99m still digesting this, but I wonder if this problem (=
errors vs non-world-ending errors vs happy path) is a problem due to peo=
ple often making warnings into exceptions?</div><div><br></div><div>I fe=
el like many devs/frameworks =E2=80=9Cabuse=E2=80=9D (for lack of a bett=
er word) the error handling system to make everything into a world-endin=
g-error when it is not.&nbsp;</div><div><br></div><div>Even over the las=
t few versions of PHP, more and more warnings have turned into exception=
s that maybe ought not be.</div><div><br></div><div>Overall, this has re=
sulted in a somewhat more inconsistent language than it was previously. =
For example, you used to be able to consider an array as a field of infi=
nite nulls. You could iterate over an infinite set of keys and get nothi=
ng but null. This made it easier to explain to junior devs at the time. =
Now, you have to explain it as a hash-map-but-sometimes-array-thing that=
 emits warnings when a key doesn=E2=80=99t exist but will still give you=
 null.&nbsp;</div><div><br></div><div>We are currently in this weird pla=
ce between =E2=80=9Cinfinite field of nulls=E2=80=9D and =E2=80=9Csparse=
 array/hash-map=E2=80=9D but not quite either one =E2=80=94 depending on=
 what you do with that warning.&nbsp;</div><div><br></div><div>It would =
be great if we could pick one and I think it would also solve the whole =
=E2=80=9Cis null an error or a value=E2=80=9D problem.&nbsp;</div><div><=
br></div><div>I personally wouldn=E2=80=99t like checked exceptions. I h=
ave PTSD from Java=E2=80=99s, so just hearing that phrase gives me flash=
backs of catching dozens of potential exceptions. In Go, yes there is so=
me boilerplate, but it=E2=80=99s not that bad and it easy to deal with, =
especially with IDE support.&nbsp;</div><div><br></div><div>As for a Res=
ult type, that=E2=80=99s already possible in user-land; what does bringi=
ng it to the engine get us? Is it just a lightweight exception without a=
 trace to prevent the cost of generation? Why not just have a pool of ex=
ceptions that you can just modify the message?</div><div><br></div><div =
id=3D"sig121229152">=E2=80=94 Rob</div></body></html>
--e8ba629ad24c4abe9a86fffb851d303b--