Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127193
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 27 Apr 2025 01:04:49 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <f32685bc-9815-4fcd-915e-e4898e373bef@app.fastmail.com>
In-Reply-To: <7e923206-139a-4442-824e-895b09d563a2@app.fastmail.com>
References: <39597a9c-6854-40c6-a529-32b2b178cb27@app.fastmail.com>
 <7e923206-139a-4442-824e-895b09d563a2@app.fastmail.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 Sat, Apr 26, 2025, at 11:19 AM, Rob Landers wrote:

> Hey Larry,
>
> I=E2=80=99m still digesting this, but I wonder if this problem (errors=
 vs=20
> non-world-ending errors vs happy path) is a problem due to people ofte=
n=20
> making warnings into exceptions?
>
> I feel like many devs/frameworks =E2=80=9Cabuse=E2=80=9D (for lack of =
a better word)=20
> the error handling system to make everything into a world-ending-error=20
> when it is not.=20

Yes, it's common for devs today to use exceptions in inappropriate ways.=
  I've done it myself at times.  The problem is that we don't have a too=
l fit-for-purpose for "your input is invalid in a totally predictable wa=
y."  So you can either squeeze an error code into the return value (null=
 or otherwise), which sucks, or abuse exceptions, which sucks.  That's e=
xactly the issue I want to solve, by offering a tool more purpose built =
for that case.

> Even over the last few versions of PHP, more and more warnings have=20
> turned into exceptions that maybe ought not be.
>
> Overall, this has resulted in a somewhat more inconsistent language=20
> than it was previously. For example, you used to be able to consider a=
n=20
> array as a field of infinite nulls. You could iterate over an infinite=20
> set of keys and get nothing but null. This made it easier to explain t=
o=20
> junior devs at the time. Now, you have to explain it as a=20
> hash-map-but-sometimes-array-thing that emits warnings when a key=20
> doesn=E2=80=99t exist but will still give you null.=20
>
> We are currently in this weird place between =E2=80=9Cinfinite field o=
f nulls=E2=80=9D=20
> and =E2=80=9Csparse array/hash-map=E2=80=9D but not quite either one =E2=
=80=94 depending on=20
> what you do with that warning.=20

Treating arrays as an infinite series of nulls, however... no, that's al=
ways been a developer error.  If that was the mental model you were work=
ing from, it's an incorrect mental model, and it always has been, since =
forever.  Arguably it's PHP's fault for letting you develop that broken =
mental model because it didn't complain loudly; both PHP and MySQL start=
ed life with lots of "we'll quietly assume what you probably meant and n=
ot tell you that you're wrong" features, and both have had a very long, =
very painful process of correcting that fundamental mistake.  Anyone wor=
king from an "infinite series of nulls" model has been an unfortunate vi=
ctim of that design flaw.

It's possible we could use light-checked exceptions as a better way of s=
ignaling "hey, you're reading an invalid key".  So far I've only conside=
red them as a function-boundary thing, but we could probably look into r=
aising them implicitly for certain read operations.  (Maybe only on obje=
cts that are using Gina's forthcoming Fetch interfaces? I dunno.)

> It would be great if we could pick one and I think it would also solve=20
> the whole =E2=80=9Cis null an error or a value=E2=80=9D problem.=20

Just having an "alternate null" is not viable for many reasons, which I =
go into in the article I linked before so I won't repeat it here.

> I personally wouldn=E2=80=99t like checked exceptions. I have PTSD fro=
m Java=E2=80=99s,=20
> so just hearing that phrase gives me flashbacks of catching dozens of=20
> potential exceptions. In Go, yes there is some boilerplate, but it=E2=80=
=99s=20
> not that bad and it easy to deal with, especially with IDE support.=20

As the Midori article I linked explains, the PTSD you have from Java exc=
eptions is not an issue with checked exceptions; it's an issue with Java=
's terribly designed exception system, combined with all values being in=
herently nullable.

A well-designed checked exception system doesn't "force you to handle al=
l these error cases".  A well-designed system "tells you every error cas=
e that you need to think about, and helps you deal with it."  Smart usag=
e of interfaces on the error values can make dealing with a whole class =
of issues easier, and some more ergonomic syntax than try-catch (such as=
 Rust's ?) can make it less cumbersome.

In a sense, checked exceptions show you exactly what you need to do in o=
rder to turn a partial function (that just dies on certain values in its=
 input range) into a total function with two return channels (because yo=
u'll always get back a legit value, just sometimes the legit value is on=
 the error pathway.)  That both surfaces the unhappy paths (that any rob=
ust code should handle) and simplifies handling them.

> As for a Result type, that=E2=80=99s already possible in user-land; wh=
at does=20
> bringing it to the engine get us? Is it just a lightweight exception=20
> without a trace to prevent the cost of generation? Why not just have a=20
> pool of exceptions that you can just modify the message?

A general purpose Result type requires generics, or else you lose all ty=
pe info on what the real return value's type is.  We don't have generics=
, so that's simply not an option.  The separate channel approach gives u=
s all the benefits of a Result type without the need for generics, and i=
t's standardized in the language.

A general purpose Result type is also very clumsy to use in practice, un=
less you have syntax optimized for working with it.  Rust has its match =
statement (which supports pattern matching, decomposition, and multi-lin=
e statements specifically for dissecting a Result type) and ? operator, =
which is a one-character way to "pass on" the error to the caller, as th=
ough it were an unchecked exception.  For PHP, we'd probably want a diff=
erent set of syntax tools as our working model is different than Rust's.=
  What those would be, I don't know yet.  Hence this thread.

--Larry Garfield