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. вт, 6 февр. 2024 г. в 18:20, Alexander Pravdin <alex.prav...@interi.co>: > On Wed, Feb 7, 2024 at 12:00 AM Григорий Senior PHP / Разработчик Web > <6562...@gmail.com> wrote: > > > > 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. > > 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. > > > > ``` > > > > вт, 6 февр. 2024 г. в 17:56, Arvids Godjuks <arvids.godj...@gmail.com>: > > > > > > > > > > > On Tue, 6 Feb 2024 at 16:39, Arvids Godjuks <arvids.godj...@gmail.com> > > > wrote: > > > > > >> > > >> > > >> On Tue, 6 Feb 2024 at 15:58, Григорий Senior PHP / Разработчик Web < > > >> 6562...@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 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 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 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 > 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 - предпочитаемый способ > > >>> связи > > >>> https://t.me/gzhegow / https://t.me/%2B375296764868 / Telegram > > >>> 6562...@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 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īds Godjuks > > >> +371 26 851 664 > > >> arvids.godj...@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īds Godjuks > > > +371 26 851 664 > > > arvids.godj...@gmail.com > > > Telegram: @psihius https://t.me/psihius > > > > > > > > > -- > > +375 (29) 676-48-68 <+375296764868> / Mobile - предпочитаемый способ > связи > > https://t.me/gzhegow / https://t.me/%2B375296764868 / Telegram > > 6562...@gmail.com > -- +375 (29) 676-48-68 <+375296764868> / Mobile - предпочитаемый способ связи https://t.me/gzhegow / https://t.me/%2B375296764868 / Telegram 6562...@gmail.com
