Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122324
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>
In-Reply-To: <3db4fbe0-22f4-44e2-a1a6-6cd85287df56@app.fastmail.com>
Date: Wed, 7 Feb 2024 11:21:05 +0100
Message-ID: <CAPzBOBPKF6CSzVcuxq1Gz44uZKLJA6yJ73mTtVidYXXg0z0pYA@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: 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: landers.robert@gmail.com (Robert Landers)

On Tue, Feb 6, 2024 at 9:22=E2=80=AFPM Larry Garfield <larry@garfieldtech.c=
om> 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 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/cat=
ch
> > 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 before=
 -
> > 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 functio=
n or
> > in place I call the function. I want to share this experience, and imag=
ined
> > it would be better for all users. It could be done without 2 classes, 1=
0
> > functions and work with push/pop/current (closer to ob_start/ob_get_cle=
an
> > story).
> > I guess it could be implemented if `raise` world will put any data to t=
he
> > current error bag in the stack. Exactly if the current error bag is pre=
sent
> > (declared manually like you can declare() strict types or ticks for som=
e
> > scope).
> >
> > I agree that there's more mandatory problems to solve that I didn't eve=
n
> > 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 late=
r
> >
> > 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 believe=
 in
> > "watching for".
> I think there's a subtle but important difference here between what you'r=
e 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 po=
ssible ways to do that, both of them bad: Unchecked exceptions and globals.
>
> What I described, based on the syntax you offered, is checked exceptions,=
 which necessarily means changing the function signature.  Error handling i=
s part of the contract of a function.  If its error handling changes, it *s=
hould* have a signature change to indicate that.  (That unchecked exception=
s do not do that is the problem with unchecked exceptions.)  So if "no chan=
ges to existing code" is the goal, checked exceptions as I describe them ar=
e not the answer you are looking for.
>
> It seems from your latest message that you're describing more a generaliz=
ed version of `json_last_error()` and similar functions.  The problem there=
 is that such an API design is generally considered very poor practice outs=
ide of C, because it's all necessarily based on globals and "hope you remem=
bered to check the thing that no one told you to check and is not even slig=
htly obvious to check".  That is not something I would want better support =
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.  There's=
 definitely cleaner monadic solutions (which I've written before and are qu=
ite neat) using a writer/logger monad, but that again doesn't meet your "do=
n't change existing code" requirement.  I don't think anything the language=
 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