Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122326
MIME-Version: 1.0
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>
 <3db4fbe0-22f4-44e2-a1a6-6cd85287df56@app.fastmail.com> <CAPzBOBPKF6CSzVcuxq1Gz44uZKLJA6yJ73mTtVidYXXg0z0pYA@mail.gmail.com>
 <CAK=iT=XuNUY8nRq1giix-yZ6SeyFaE++3hcuoNQtR6WVya74UQ@mail.gmail.com>
In-Reply-To: <CAK=iT=XuNUY8nRq1giix-yZ6SeyFaE++3hcuoNQtR6WVya74UQ@mail.gmail.com>
Date: Wed, 7 Feb 2024 12:57:57 +0100
Message-ID: <CAPzBOBPvkNixG=64KQY3-HgtWWya4Hd1ERUw+Y8Vb8625SZ8WQ@mail.gmail.com>
To: =?UTF-8?B?0JPRgNC40LPQvtGA0LjQuSBTZW5pb3IgUEhQIC8g0KDQsNC30YDQsNCx0L7RgtGH0LjQuiBXZWI=?= <6562680@gmail.com>
Cc: 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: landers.robert@gmail.com (Robert Landers)

On Wed, Feb 7, 2024 at 11:27=E2=80=AFAM =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
<6562680@gmail.com> wrote:
>
> Yes, that was the second build of the error bag I presented in the github=
 ticket.
> First one was a Trait that added an error bag as property in class and re=
turned an array with two results.
>
> The trouble was you have to refactor all places you used your function do=
esn't matter, want you or not.
>
> And the last build just collects errors to the global stack of error bags=
 allowing you to stay untouched by the existing code.
>
> Of course, if code should start to return null/null-object as result - yo=
u have to implement that (refactoring the places where null is inapplicable=
), but error collection itself won't change existing code then, it works li=
ke an observer pattern now.
>
> =D1=81=D1=80, 7 =D1=84=D0=B5=D0=B2=D1=80. 2024=E2=80=AF=D0=B3. =D0=B2 13:=
21, Robert Landers <landers.robert@gmail.com>:
>>
>> On Tue, Feb 6, 2024 at 9:22=E2=80=AFPM Larry Garfield <larry@garfieldtec=
h.com> wrote:
>> >
>> > 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 no=
t
>> > > 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/=
catch
>> > > all places you use that function (sometimes you predict possible err=
or, and
>> > > yes, write return class/enum to extend/refactor it later)
>> > > (and yes, if old code did not support returning null/null-object bef=
ore -
>> > > 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 s=
ave
>> > > 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 t=
he
>> > > second method, then debug the second method.
>> > >
>> > > So what's in rest? Arrays collection of warnings and errors. Changin=
g
>> > > 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 func=
tion or
>> > > in place I call the function. I want to share this experience, and i=
magined
>> > > 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_=
clean
>> > > story).
>> > > I guess it could be implemented if `raise` world will put any data t=
o the
>> > > current error bag in the stack. Exactly if the current error bag is =
present
>> > > (declared manually like you can declare() strict types or ticks for =
some
>> > > scope).
>> > >
>> > > I agree that there's more mandatory problems to solve that I didn't =
even
>> > > know about.
>> > > I tried to talk about error handling with a few developers, all of t=
hem
>> > > recommend:
>> > > 1. Use exceptions, don't make anything fresh
>> > > 2. Do validation at the script start to reduce the count of errors l=
ater
>> > >
>> > > I've just encountered cases where bugs come from within - once you
>> > > integrate a really bad external system with its own checks, which ar=
e
>> > > described in hundreds of documents, I'm sure you'll encounter new bu=
gs 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 beli=
eve in
>> > > "watching for".
>> > I think there's a subtle but important difference here between what yo=
u're describing as the problem and what you implied the solution was (which=
 I then ran with).
>> >
>> > What you're talking about is trying to change the error handling model=
 of existing code without changing function signatures.  There are only two=
 possible ways to do that, both of them bad: Unchecked exceptions and globa=
ls.
>> >
>> > What I described, based on the syntax you offered, is checked exceptio=
ns, which necessarily means changing the function signature.  Error handlin=
g is part of the contract of a function.  If its error handling changes, it=
 *should* have a signature change to indicate that.  (That unchecked except=
ions do not do that is the problem with unchecked exceptions.)  So if "no c=
hanges 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 genera=
lized version of `json_last_error()` and similar functions.  The problem th=
ere is that such an API design is generally considered very poor practice o=
utside of C, because it's all necessarily based on globals and "hope you re=
membered to check the thing that no one told you to check and is not even s=
lightly obvious to check".  That is not something I would want better suppo=
rt for in the language at all.  There's probably cleaner ways to emulate it=
 in user-space, but that is for a particular application to sort out.  Ther=
e'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 don't think anything the langu=
age can do will meet that requirement and be a good design.
>> >
>> > --Larry Garfield
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: https://www.php.net/unsub.php
>> >
>>
>> Oh wow, this conversation got really interesting while I was asleep :D
>>
>> I think this could actually be interesting in a
>> semi-backwards-compatible way, by just adding some syntax sugar:
>>
>> function getResult(): ?Result, ?ResultError {
>>   if($error) return null, $error;
>> }
>>
>> instead of, but this would still work when destructuring:
>>
>> function getResult(): array {
>>   if($error) return [null, $error);
>> }
>>
>> This would still work (the "backwards compatible" part):
>>
>> [$result, $error] =3D getResult();
>>
>> or this:
>>
>> $result, $error =3D getResult();
>>
>> Essentially, return types with a comma are just a "strongly typed
>> array" and a comma on the left-hand side of assignment is just a
>> destructure.
>>
>> Robert Landers
>> Software Engineer
>> Utrecht NL
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: https://www.php.net/unsub.php
>>
>
>
> --
> +375 (29) 676-48-68 / Mobile - =D0=BF=D1=80=D0=B5=D0=B4=D0=BF=D0=BE=D1=87=
=D0=B8=D1=82=D0=B0=D0=B5=D0=BC=D1=8B=D0=B9 =D1=81=D0=BF=D0=BE=D1=81=D0=BE=
=D0=B1 =D1=81=D0=B2=D1=8F=D0=B7=D0=B8
> https://t.me/gzhegow / https://t.me/%2B375296764868 / Telegram
> 6562680@gmail.com

Please don't top-post your replies. It's very rude.

If it's just syntax around arrays, it's something that doesn't require
much (if any refactoring)

$result =3D getResult();

could be seen by PHP as the same as

[$result] =3D getResult();

Allowing you to implement things as fast or as slow as you wanted to,
or ignore errors completely.

Robert Landers
Software Engineer
Utrecht NL