Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122312
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>
In-Reply-To: <CAL0xaBFybT7F1J5fMZyz9JkeP79iVveCeFTRUFKzQgdgAPDYPQ@mail.gmail.com>
	=?UTF-8?B?Yg==?= <6562680@gmail.com>
Date: Tue, 6 Feb 2024 22:56:19 +0300
Message-ID: <CAK=iT=W3pC5xXa8cMmqdTmog6bOC-oYo2csetQADYEUE3+yCZw@mail.gmail.com>
To: Arvids Godjuks <arvids.godjuks@gmail.com>, larry@garfieldtech.com, 
	internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000006eb00610bbfbff"
Subject: Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301
From: 6562680@gmail.com (=?UTF-8?B?0JPRgNC40LPQvtGA0LjQuSBTZW5pb3IgUEhQIC8g0KDQsNC30YDQsNCx0L7RgtGH0LjQuiBXZQ==?==?UTF-8?B?Yg==?=)

--000000000000006eb00610bbfbff
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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/catch
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 function or
in place I call the function. I want to share this experience, and imagined
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 to 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 them
recommend:
1. Use exceptions, don't make anything fresh
2. Do validation at the script start to reduce the count of errors later

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".

--=20
+375 (29) 676-48-68 <+375296764868> / 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

--000000000000006eb00610bbfbff--