Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122318
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-144-ge5821d614e-fm-20240125.002-ge5821d61
MIME-Version: 1.0
Message-ID: <3db4fbe0-22f4-44e2-a1a6-6cd85287df56@app.fastmail.com>
In-Reply-To: 
 <CAK=iT=W3pC5xXa8cMmqdTmog6bOC-oYo2csetQADYEUE3+yCZw@mail.gmail.com>
References: 
 <CAK=iT=UrMCPw5ydCnxa_87ws6xKRO5Y3qJnmchczgDds8u660A@mail.gmail.com>
 <CABigaAUjSx3-vEaQhPk-toJTSg+J3CLrO3otpm1g6hqbYyQKvw@mail.gmail.com>
 <CAK=iT=WgsEZjyu3Y2wTWvycqCsYH7MrLsZgERZK3u75U08ePpA@mail.gmail.com>
 <CAL0xaBHfEMs1BVAMZOuFCUpb9orNSRD0YDhu=3wJAGK7K0_=dg@mail.gmail.com>
 <CAK=iT=XDVcs+y4XDmGu2re137i2yD9LiEj1-HLvyxxxrb8jFUw@mail.gmail.com>
 <CAK=iT=UDUjCZ-25k_MkHFO7uKdWAqoJxdWLVBGM2_SYDk-JyAg@mail.gmail.com>
 <742f202d-7990-4f51-b903-7a15e3fd33c2@app.fastmail.com>
 <CAL0xaBFybT7F1J5fMZyz9JkeP79iVveCeFTRUFKzQgdgAPDYPQ@mail.gmail.com>
 <CAK=iT=W3pC5xXa8cMmqdTmog6bOC-oYo2csetQADYEUE3+yCZw@mail.gmail.com>
Date: Tue, 06 Feb 2024 20:21:52 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Feb 6, 2024, at 7:56 PM, =D0=93=D1=80=D0=B8=D0=B3=D0=BE=D1=80=D0=
=B8=D0=B9 Senior PHP / =D0=A0=D0=B0=D0=B7=D1=80=D0=B0=D0=B1=D0=BE=D1=82=D1=
=87=D0=B8=D0=BA Web wrote:
> Thanks Larry, I will read both articles next weekend.
>
> Am not even talking about changing `throw` to `raise`.
>
> Am talking only about:
> - production ready code
> - that should be able to refactor with error collectors (that was not
> implemented years ago)
> - without touching return types
> - without touching input arguments of existing code
> - without possible code fall after throw exception: you have to try/ca=
tch
> all places you use that function (sometimes you predict possible error=
, and
> yes, write return class/enum to extend/refactor it later)
> (and yes, if old code did not support returning null/null-object befor=
e -
> you have to refactor return types then)
>
> While working with queues you have a list of tasks
> - then you reduce it to smaller with reducer (unique/filter/merge)
> - then do some queries
> - then walk initial data using reduced results: copying reports to save
> errors/warnings to each task separately
>
> It cannot be solved with exceptions. In addition, large arrays throw
> exceptions that cause timeloss. It's definitely not a tool for.
> Also your method could return many errors (today - only one
> error/exception), and you need to write a second method, then call the
> second method, then debug the second method.
>
> So what's in rest? Arrays collection of warnings and errors. Changing
> return types or passing second-return by reference.
>
> [ Enum case ~ DTO output ] covers newly written code. Old code is
> uncovered. You have to rewrite a full tree, that's why some trick is
> necessary.
>
> I did it my way with an error bag stack. I enable it inside the functi=
on or
> in place I call the function. I want to share this experience, and ima=
gined
> it would be better for all users. It could be done without 2 classes, =
10
> functions and work with push/pop/current (closer to ob_start/ob_get_cl=
ean
> story).
> I guess it could be implemented if `raise` world will put any data to =
the
> current error bag in the stack. Exactly if the current error bag is pr=
esent
> (declared manually like you can declare() strict types or ticks for so=
me
> scope).
>
> I agree that there's more mandatory problems to solve that I didn't ev=
en
> know about.
> I tried to talk about error handling with a few developers, all of them
> recommend:
> 1. Use exceptions, don't make anything fresh
> 2. Do validation at the script start to reduce the count of errors lat=
er
>
> I've just encountered cases where bugs come from within - once you
> integrate a really bad external system with its own checks, which are
> described in hundreds of documents, I'm sure you'll encounter new bugs=
 once
> the "working" code is released to production. And then you will need to
> quickly and easily reorganize it.
>
> And you can't.
> And you will be sad.
> And, "PHP moves differently" is a completely wrong principle, I believ=
e in
> "watching for".
I think there's a subtle but important difference here between what you'=
re describing as the problem and what you implied the solution was (whic=
h I then ran with).

What you're talking about is trying to change the error handling model o=
f existing code without changing function signatures.  There are only tw=
o possible ways to do that, both of them bad: Unchecked exceptions and g=
lobals.

What I described, based on the syntax you offered, is checked exceptions=
, which necessarily means changing the function signature.  Error handli=
ng is part of the contract of a function.  If its error handling changes=
, it *should* have a signature change to indicate that.  (That unchecked=
 exceptions do not do that is the problem with unchecked exceptions.)  S=
o if "no changes to existing code" is the goal, checked exceptions as I =
describe them are not the answer you are looking for.

It seems from your latest message that you're describing more a generali=
zed version of `json_last_error()` and similar functions.  The problem t=
here is that such an API design is generally considered very poor practi=
ce outside of C, because it's all necessarily based on globals and "hope=
 you remembered to check the thing that no one told you to check and is =
not even slightly obvious to check".  That is not something I would want=
 better support for in the language at all.  There's probably cleaner wa=
ys to emulate it in user-space, but that is for a particular application=
 to sort out.  There's definitely cleaner monadic solutions (which I've =
written before and are quite neat) using a writer/logger monad, but that=
 again doesn't meet your "don't change existing code" requirement.  I do=
n't think anything the language can do will meet that requirement and be=
 a good design.

--Larry Garfield