Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122295
MIME-Version: 1.0
References: <CAK=iT=UrMCPw5ydCnxa_87ws6xKRO5Y3qJnmchczgDds8u660A@mail.gmail.com>
 <CAL0xaBGhO3YAgvkNCTzONpZzh9a_p58yBQtQpe=4FLq8uHs6Xg@mail.gmail.com> <CAL0xaBESJwyg7FRN3FP-Sx2z46bBjUgW2U5NeB5hFLoEjLQmyA@mail.gmail.com>
In-Reply-To: <CAL0xaBESJwyg7FRN3FP-Sx2z46bBjUgW2U5NeB5hFLoEjLQmyA@mail.gmail.com>
	=?UTF-8?B?Yg==?= <6562680@gmail.com>
Date: Tue, 6 Feb 2024 17:59:29 +0300
Message-ID: <CAK=iT=UEu4iDKe2Zv=L6ffuaBpUNHk3B4ONhPw0E1Et-ks6HzA@mail.gmail.com>
To: Arvids Godjuks <arvids.godjuks@gmail.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000005f78bb0610b7d59d"
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==?=)

--0000000000005f78bb0610b7d59d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Sending you private emails made because "answer" button in Gmail selects
only you to receive.
Sending you private emails that don't even read signs to me you don't need
my answers and have no benefits from reading. But you deny, dont even want
to understand. And notify all subscribers about what you don't want to
understand, and about my mistakes.

```
It's business-level, capitalism, if you want so, issue. And it sounds like
"we won't pay you for your mistakes".

There's no magic pill that accidentally forces business to understand you
now need errors collection and it needs at least two more days for
"design-level" refactoring without business benefit. Also no magic pills to
force the business owner to give you that 2 days before you face that
requirement (you know, deadlines stuff).

Refactoring should be reduced by time as much as possible otherwise you
feel more stress on your job. I have no goal to convince you that this is
necessary, I solved this problem for myself. But at the language level it
can be solved more conveniently and better, and you will also benefit from
this.

All languages work as a stack. So errors could be collected as a stack on
language level. Directly in place you need that stack instead of
everywhere. Also forcing to close applications is safe-shield, instead of
validation errors that could be found anywhere. PHP devs in most even
imagined a solution that "you have to do validation as much earlier as you
can". But... remote api responses still become from inside to outside,
remote api requirements that accidentally arrive still become once your
code is ready, and unpredictable.

That simple enhancement allows you to implement error collection and
dont touch your methods and signatures. Nice and easy. Or you can believe
in `truth` and deny ideas because it does not correlate with your
principles.
```

=D0=B2=D1=82, 6 =D1=84=D0=B5=D0=B2=D1=80. 2024=E2=80=AF=D0=B3. =D0=B2 17:56=
, Arvids Godjuks <arvids.godjuks@gmail.com>:

>
>
> On Tue, 6 Feb 2024 at 16:39, Arvids Godjuks <arvids.godjuks@gmail.com>
> wrote:
>
>>
>>
>> On Tue, 6 Feb 2024 at 15:58, =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:
>>
>>> Hello, please discuss about error collecting implementation in next PHP
>>> releases
>>>
>>> Exceptions have common differences that restrict using them to collect
>>> errors
>>> 1. Timeloss (trace collection) on call new() on any class that implemen=
ts
>>> \Throwable
>>> 2. To collect errors and return it to the upper level you have to chang=
e
>>> the return signature, so most of the time rewrite the full tree and
>>> change
>>> all signatures, that's inapplicable and causes more refactor time witho=
ut
>>> any benefits
>>> 3. Exceptions will break code, so you need to catch them as much closel=
y
>>> as
>>> possible to place you throw it (additional refactoring)
>>>
>>> What I want from this feature:
>>> - while I am writing the api, I need not only "log" the errors, but be
>>> able
>>> to send all script errors to json output, including warnings, errors, a=
nd
>>> deep nested. It will reduce the time of debugging, otherwise i have to
>>> download log files from server or configure external system like sentry
>>> that collects all errors by groups/chains
>>>
>>> Suggested solution:
>>> - add non-breakable interface and language construct `raise` to "throw"
>>> error without collecting trace
>>> - that error could be any scalar or object, or you can implement new
>>> interface for them, keeping that is nested and taggable array
>>> - this `raise` could be catched same way as \Throwable allowing log it
>>> anywhere you need or re-`raise` again
>>> - `raise` statement won't start to collapse/break code, so it could be
>>> skipped without affecting application
>>>
>>> Current solution:
>>> a) 2 classes - ErrorBag/ErrorBagStack.
>>>
>>> b) native functions like _error()/_warning() that stores errors to the
>>> current ErrorBag if it exists.
>>>
>>> c) ErrorBag exists only if you initialize it:
>>> - from the upper level (you need to collect)
>>> - directly inside a function (you need to decide return/continue
>>> depending
>>> on its emptiness)
>>> - otherwise _error()/_warning() does nothing
>>>
>>> d) once you "catch" results of _error()/_warning() you often need it to
>>> merge the result to the current errorbag, mark it with a nesting group =
or
>>> with the tag. Nesting group is required once you debug code (you will s=
ee
>>> the log), tags will needed once you want to copy results from one bag t=
o
>>> another (closest example - reduce queue with unique function, do action=
,
>>> then work with initial data)
>>>
>>> e) useful feature is merge_as_warning($errorBag) - to prevent the curre=
nt
>>> error bag to return `true` on call ->hasErrors(). Errors are related to
>>> low
>>> level function, and possibly you already do actions that allow you just
>>> store them.
>>>
>>> f) searching inside the error bag by nesting sequence, or by tag, or by
>>> error type. Error type helps the same as try/catch, tag helps if you wa=
nt
>>> to save errors to several destinations without memory losses, and nesti=
ng
>>> will help most of the time in debugging.
>>>
>>> Thanks for your attention.
>>>
>>> --
>>> +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
>>>
>>
>> Hello,
>>
>> This is an application design-level issue, not a language issue.
>> All you need to do is implement a collector on the logger you use that
>> will store the info you want and let you ask for that info just before y=
ou
>> push data into the JSON encoder you use from that logger collector. It's=
 as
>> simple as that, you don't even need to change your existing code if it
>> already logs the information.
>>
>> --
>>
>> Arv=C4=ABds Godjuks
>> +371 26 851 664
>> arvids.godjuks@gmail.com
>> Telegram: @psihius https://t.me/psihius
>>
>
> Sending me multiple emails in private with rants is not a behaviour that'=
s
> encouraged on this list. Please read the
> https://wiki.php.net/email_etiquette_for_people_new_to_php_internals
> --
>
> Arv=C4=ABds Godjuks
> +371 26 851 664
> arvids.godjuks@gmail.com
> Telegram: @psihius https://t.me/psihius
>


--=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

--0000000000005f78bb0610b7d59d--