Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122297
MIME-Version: 1.0
References: <CAK=iT=UrMCPw5ydCnxa_87ws6xKRO5Y3qJnmchczgDds8u660A@mail.gmail.com>
 <CAL0xaBGhO3YAgvkNCTzONpZzh9a_p58yBQtQpe=4FLq8uHs6Xg@mail.gmail.com>
 <CAL0xaBESJwyg7FRN3FP-Sx2z46bBjUgW2U5NeB5hFLoEjLQmyA@mail.gmail.com>
 <CAK=iT=UEu4iDKe2Zv=L6ffuaBpUNHk3B4ONhPw0E1Et-ks6HzA@mail.gmail.com> <CAOyH9ySkTQ4P8e04X2LDJiDMpHy99kBToLOthWX0=MPKDag-Hg@mail.gmail.com>
In-Reply-To: <CAOyH9ySkTQ4P8e04X2LDJiDMpHy99kBToLOthWX0=MPKDag-Hg@mail.gmail.com>
	=?UTF-8?B?Yg==?= <6562680@gmail.com>
Date: Tue, 6 Feb 2024 18:25:25 +0300
Message-ID: <CAK=iT=Vy-PhtiD1bY3X=h5wBr7mLjdtEuz_p5kDNL5_NKMyM4g@mail.gmail.com>
To: Alexander Pravdin <alex.pravdin@interi.co>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000023c9400610b832d9"
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==?=)

--00000000000023c9400610b832d9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Short answer is yes. Glad to see that personally adapted answer.

That's why in the relevant github issue i show how to collect ONLY if you
need.
If you initialize the error bag - it collects, if not - it skips. T

So the `try/catch` statement outside means you initialized, also a special
decorator or additional command could initiate the raise collector right in
the function !

You collect only the cases you want to collect. That's the difference.



=D0=B2=D1=82, 6 =D1=84=D0=B5=D0=B2=D1=80. 2024=E2=80=AF=D0=B3. =D0=B2 18:20=
, Alexander Pravdin <alex.pravdin@interi.co>:

> On Wed, Feb 7, 2024 at 12:00=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:
> >
> > Sending you private emails made because "answer" button in Gmail select=
s
> > 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 y=
ou
> > now need errors collection and it needs at least two more days for
> > "design-level" refactoring without business benefit. Also no magic pill=
s
> 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 belie=
ve
> > in `truth` and deny ideas because it does not correlate with your
> > principles.
>
> Hey friend, easy :)
>
> You was correctly pointed out that this is an application-level issue,
> not a language one. It is your responsibility to collect anything you
> want and deal with the business when it puts some requirements. Did
> you ever experience out-of-memory issues because something in your
> application is collecting some stuff and don't dispose it? Did you
> ever work with algorithms running iterations over millions of records
> in PHP? Can you imagine a language-level bomb if PHP will collect
> anything in its own memory in every iteration of this kind and not
> dispose it during the whole request?
>
> You don't need to reply to me, just take a deep breath and think about
> it. I believe this kind of discussions is an off-topic in this mailing
> list.
>
>
> --
> Best, Alexander.
>
>
> > ```
> >
> > =D0=B2=D1=82, 6 =D1=84=D0=B5=D0=B2=D1=80. 2024=E2=80=AF=D0=B3. =D0=B2 1=
7: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
> implements
> > >>> \Throwable
> > >>> 2. To collect errors and return it to the upper level you have to
> change
> > >>> the return signature, so most of the time rewrite the full tree and
> > >>> change
> > >>> all signatures, that's inapplicable and causes more refactor time
> without
> > >>> any benefits
> > >>> 3. Exceptions will break code, so you need to catch them as much
> closely
> > >>> 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, and
> > >>> 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 ne=
w
> > >>> 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 i=
t
> 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 see
> > >>> the log), tags will needed once you want to copy results from one
> bag to
> > >>> 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
> current
> > >>> error bag to return `true` on call ->hasErrors(). Errors are relate=
d
> 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, o=
r
> by
> > >>> error type. Error type helps the same as try/catch, tag helps if yo=
u
> want
> > >>> to save errors to several destinations without memory losses, and
> nesting
> > >>> 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 th=
at
> > >> will store the info you want and let you ask for that info just
> before you
> > >> 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
> > >
> >
> >
> > --
> > +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
>


--=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

--00000000000023c9400610b832d9--