Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127260
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 01 May 2025 15:47:49 +0300
To: Matthew Weier O'Phinney <mweierophinney@gmail.com>
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] Concept: Lightweight error channels
In-Reply-To: <CAJp_myW0jv2aXa0KNz0EoVt3F9HKqTFoHSQLQDcqHXQO6889rQ@mail.gmail.com>
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>
User-Agent: Roundcube Webmail/1.4.8
Message-ID: <d7c7e7ecf7ecd08b56412262a14cd04e@glaive.pro>
Organization: SIA "Glaive.pro"
Content-Type: multipart/alternative;
 boundary="=_3f50c65619d872364229b98f7d9c50b7"
From: juris@glaive.pro (Juris Evertovskis)

--=_3f50c65619d872364229b98f7d9c50b7
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed

On 2025-04-29 17:29, Matthew Weier O'Phinney wrote:

> * Exceptions should not be used for normal application logic flow. If 
> the "error" is recoverable and/or expected, use a different mechanism 
> so you can use standard conditional branching.
> 
> As such, there are a lot of situations where I may not want to use 
> exceptions. Two common ones:
> 
> * Input validation. In most cases, _invalid input is expected_, and a 
> condition you will handle in your code. Exceptions are a really poor 
> mechanism for this.
> * "Not found" conditions, such as not finding a matching row in a 
> database or a cache. Again, this is expected, and something you should 
> handle via conditionals.

I don't want to make this into a quarrel, please consider this to be a 
genuine question -- I'm trying to understand the viewpoint behind the 
need for such "failed result" channel.

I'm considering this scenario: An update request comes into a controller 
and passes a superficial validation of field types. The 'troller invokes 
an action which in turn invokes a service or whatever the chain is. 
Somewhere along the call stack once all the data is loaded we realize 
that the request was invalid all along, e.g. the status can't be changed 
to X because that's not applicable for objects of kind B that have 
previously been in status Z.

In such situations I have found (according to my experience) the 
following solution to be a good, robust and maintainable pattern:

Once I find the request was invalid, I throw a ValidationException. No 
matter how deep in the stack I am. No matter that the callers don't know 
I might've thrown that. The exception will be caught and handled by some 
boundary layer (controller, middleware, error handler or whatever), 
formatted properly and returned to the user in a request-appropriate 
form.

I currently have no urge to return an indication of invalidity manually 
and pass it up the call stack layer by layer. Should I want that? In my 
experience such patterns (requiring each layer to do an `if` for the 
possible issue and return up the stack instead of continuing the 
execution) get very clumsy for complex actions. Or have I misunderstood 
the usecase that you had in mind?

BR,
Juris
--=_3f50c65619d872364229b98f7d9c50b7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3DUTF-8" /></head><body style=3D'font-size: 10pt; font-family: Verdana,Gen=
eva,sans-serif'>
<p id=3D"reply-intro">On 2025-04-29 17:29, Matthew Weier O'Phinney wrote:</=
p>
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">
<div id=3D"replybody1">
<div dir=3D"ltr">
<div dir=3D"ltr">&nbsp;</div>
<div class=3D"v1gmail_quote v1gmail_quote_container">
<div>* Exceptions should not be used for normal application logic flow. If =
the "error" is recoverable and/or expected, use a different mechanism so yo=
u can use standard conditional branching.</div>
<div>&nbsp;</div>
<div>As such, there are a lot of situations where I may not want to use exc=
eptions. Two common ones:</div>
<div>&nbsp;</div>
<div>* Input validation. In most cases, _invalid input is expected_, and a =
condition you will handle in your code. Exceptions are a really poor mechan=
ism for this.</div>
<div>* "Not found" conditions, such as not finding a matching row in a data=
base or a cache. Again, this is expected, and something you should handle v=
ia conditionals.</div>
</div>
</div>
</div>
</blockquote>
<p>I don't want to make this into a quarrel, please consider this to be a g=
enuine question &mdash; I'm trying to understand the viewpoint behind the n=
eed for such "failed result" channel.</p>
<p>I'm considering this scenario: An update request comes into a controller=
 and passes a superficial validation of field types. The 'troller invokes a=
n action which in turn invokes a service or whatever the chain is. Somewher=
e along the call stack once all the data is loaded we realize that the requ=
est was invalid all along, e.g. the status can't be changed to X because th=
at's not applicable for objects of kind B that have previously been in stat=
us Z.</p>
<p>In such situations I have found (according to my experience) the followi=
ng solution to be a good, robust and maintainable pattern:</p>
<p>Once I find the request was invalid, I throw a ValidationException. No m=
atter how deep in the stack I am. No matter that the callers don't know I m=
ight've thrown that. The exception will be caught and handled by some bound=
ary layer (controller, middleware, error handler or whatever), formatted pr=
operly and returned to the user in a request-appropriate form.</p>
<p>I currently have no urge to return an indication of invalidity manually =
and pass it up the call stack layer by layer. Should I want that? In my exp=
erience such patterns (requiring each layer to do an `if` for the possible =
issue and return up the stack instead of continuing the execution) get very=
 clumsy for complex actions. Or have I misunderstood the usecase that you h=
ad in mind?</p>
<p>BR,<br />Juris</p>

</body></html>

--=_3f50c65619d872364229b98f7d9c50b7--