Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127263
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 01 May 2025 08:56:04 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <258b8500-af7d-4cd5-8b40-7a2f08d5feaf@app.fastmail.com>
In-Reply-To: <d7c7e7ecf7ecd08b56412262a14cd04e@glaive.pro>
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>
 <8ba39427-bc2d-4c2a-90d8-648371e4f576@app.fastmail.com>
 <CA+Jpaj=WEGBuC73nTrfYYQ+xpEmBRGHACUTbdWK1NLOn+knH8w@mail.gmail.com>
 <CAJp_myW0jv2aXa0KNz0EoVt3F9HKqTFoHSQLQDcqHXQO6889rQ@mail.gmail.com>
 <d7c7e7ecf7ecd08b56412262a14cd04e@glaive.pro>
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 Thu, May 1, 2025, at 7:47 AM, Juris Evertovskis wrote:
> On 2025-04-29 17:29, Matthew Weier O'Phinney wrote:
>
>> =20
>> * Exceptions should not be used for normal application logic flow. If=
 the "error" is recoverable and/or expected, use a different mechanism s=
o you can use standard conditional branching.
>> =20
>> As such, there are a lot of situations where I may not want to use ex=
ceptions. Two common ones:
>> =20
>> * Input validation. In most cases, _invalid input is expected_, and a=
 condition you will handle in your code. Exceptions are a really poor me=
chanism for this.
>> * "Not found" conditions, such as not finding a matching row in a dat=
abase or a cache. Again, this is expected, and something you should hand=
le via conditionals.
> I don't want to make this into a quarrel, please consider this to be a=20
> genuine question =E2=80=94 I'm trying to understand the viewpoint behi=
nd the=20
> need for such "failed result" channel.
>
> I'm considering this scenario: An update request comes into a=20
> controller and passes a superficial validation of field types. The=20
> 'troller invokes an action which in turn invokes a service or whatever=20
> the chain is. Somewhere along the call stack once all the data is=20
> loaded we realize that the request was invalid all along, e.g. the=20
> status can't be changed to X because that's not applicable for objects=20
> of kind B that have previously been in status Z.
>
> In such situations I have found (according to my experience) the=20
> following solution to be a good, robust and maintainable pattern:
>
> Once I find the request was invalid, I throw a ValidationException. No=20
> matter how deep in the stack I am. No matter that the callers don't=20
> know I might've thrown that. The exception will be caught and handled=20
> by some boundary layer (controller, middleware, error handler or=20
> whatever), formatted properly and returned to the user in a=20
> request-appropriate form.
>
> I currently have no urge to return an indication of invalidity manuall=
y=20
> and pass it up the call stack layer by layer. Should I want that? In m=
y=20
> experience such patterns (requiring each layer to do an `if` for the=20
> possible issue and return up the stack instead of continuing the=20
> execution) get very clumsy for complex actions. Or have I misunderstoo=
d=20
> the usecase that you had in mind?
>
> BR,
> Juris

The key distinction is here:

> Somewhere along the call stack once all the data is=20
> loaded we realize that the request was invalid all along

combined with:

> No matter that the callers don't=20
> know I might've thrown that.

Addressing the second part first, unchecked exceptions means I have no i=
dea at all if an exception is going to get thrown 30 calls down the stac=
k from me.  Literally any line in my function that calls anything could =
be the last.  Is my code ready for that?  Can it handle that?  Or do I n=
eed to put a try-finally inside every function just in case?

Admittedly in a garbage collected language that concern is vastly reduce=
d, to the point most people don't think about that concern.  But that's =
not because it's gone away entirely.  Are you writing a file and need to=
 write a terminal line to it before closing the handle?  Are you in the =
middle of a DB transaction that isn't using a closure wrapper for auto-c=
losing (which PDO natively does not)? =20

Technically, if you're writing this code:

$pdo->beginTransaction();

foreach ($something as $val) {
  $write =3D transform($val);
  $pdo->query('write $write here');
}

$pdo->commit();

That's unsafe because transform() might throw, and if it does, the commi=
t() line is never reached.  So you really have to put it in a try-catch-=
finally.  (Usually people push that off to a wrapping closure these days=
, but that introduces extra friction and you have to know to do it.)

Or similarly,=20

$fp =3D fopen('out.csv', 'w');
fwrite($fp, "Header here");
foreach ($input as $data) {
  $line =3D transform($data);
  fputcsv($fp, $line);
}
fwrite($fp, "Footer here");
fclose($fp);

If transform() throws on the 4th entry, you now have an incomplete file =
written to disk.  And *literally any function you could conceive of* cou=
ld do this to you.  The contract of every function is implicitly "and I =
might also unwind the call stack 30 levels at any time and crash the pro=
gram, cool?"

You are correct that unchecked exceptions let you throw from way down in=
 the stack if something goes wrong later.  Which brings us back to the f=
irst point: If that's a problem, it's a code smell that you should be va=
lidating your data sooner.  This does naturally lead to a different arch=
itectural approach.  Error return channels are an "in the small" feature=
.  They're intended to make the contract between one function and anothe=
r more robust.  One can build a system-wide error pattern out of them, b=
ut they're fundamentally an in-the-small feature.

So in the example you list, I would offer:

1. Do more than "superficial validation" at the higher level.  Validate =
field types *and* that a user is authorized to write this value (for exa=
mple).
2. As discussed, we do need some trivially easy way to explicitly defer =
an error value back to our caller.  That should be easy enough that it's=
 not a burden to do, but still explicit enough that both the person read=
ing and writing the code know that an error is being propagated.  This s=
till requires research to determine what would work best for PHP.

Wouldn't the heavy use of error return channels create additional fricti=
on in some places and cause us to shift how we write code?  Yes, grassho=
pper, that is the point. :-)  The language should help us write robust, =
error-proof code, and the affordances and frictions should naturally nud=
ge us in that direction.  Just as explicit typing makes certain patterns=
 less comfortable and therefore we move away from them, and are better f=
or it.

--Larry Garfield