Re: Feature request: https://github.com/php/php-src/issues/13301
| From: | Григорий Senior PHP / Разработчик We b | Date: | Tue, 06 Feb 2024 16:13:20 +0000 |
| Subject: | Re: Feature request: https://github.com/php/php-src/issues/13301 | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-122304@lists.php.net to get a copy of this message | ||
Btw, i agree about Javascript, but on a low level it produces the most
clean code, because there's no types and rules. All types moved to
TypeScript's client side compiler.
JS 15 years ago ACCIDENTALLY created a pipeline. Named it "Promise". We
spent years after to understand that while (true) and then/catch should be
different patterns.
вт, 6 февр. 2024 г. в 19:08, Григорий Senior PHP / Разработчик Web <
6562680@gmail.com>:
> My function seems like this:
>
> ```
> _error_bag_error(error) {
> if (stack.errorBag) {
> stack.errorBag.add(error);
> }
> }
> ```
>
> It does nothing if i didn't initialize the error bag manually.
> I should call _error_bag() inside the current function to create one in
> the stack, or _error_bag_push() (and then _error_bag_pop()) outside the
> function to collect children.
>
> Doctrine's main problem is the dreadnought that throws low level
> exceptions and forces developers to spend weeks to understand "wow, that's
> the way it should be". Funny but painful. For one small benefit - reducing
> the count of queries by unique insertions/deletions, maybe 10% of queries
> are removed.
>
> вт, 6 февр. 2024 г. в 18:54, Arvids Godjuks <arvids.godjuks@gmail.com>:
>
>> JavaScript is JavaScript - it's not a good role model to look at. If
>> anything, JavaScript is a collection of things of how not to design a
>> language :)
>>
>> What you are looking for is Golang.
>>
>> The level of changes you are proposing require it to go thriugh an RFC
>> process, have 2/3rds of voters to agree to it. Tland that is after a
>> feasibility study is even done - engine might not even allow to implement
>> such thi g and require exte sive modifications for a thing that should be
>> done on application level to begin with.
>>
>> And memory usage is one of the biggest points against it - engine
>> allowing to store I side it arbitrary data that is logged by application on
>> a per-request level is just a bad idea. People will shove megabytes of logs
>> into it in a loop and them file reports "why is php using 2 GB of RAM?" -
>> this is literally a daily question you get woth relation to Doctrine when
>> people try to run bulk operations, do not disable trace logger and them run
>> into the memory limit.
>>
>>
>> What you are proposing is a footgun at it's finest and PHP has a rich
>> history of those and we have learned from the experience as a community.
>> Things like this are left to the userland. There are many libraries that
>> help handle this.
>>
>> On Tue, Feb 6, 2024, 17:35 Григорий Senior PHP / Разработчик Web <
>> 6562680@gmail.com> wrote:
>>
>>> Javascript is closer to.
>>>
>>> It allows you to throw anything, but it is still the throw statement,
>>> keeping in the mind the async nature of js - memory and processor stuff
>>> is
>>> shared by the time.
>>>
>>> JS seniors usually hate those guys who throw anything except language
>>> Error
>>> class because they skipped the mandatory level of programming - OOP. They
>>> are now taking fun from it. We're tired of OOP for now. Once you work
>>> with
>>> batches/queue/bulks you need pipelines and chaining, and there's a throw
>>> works only to stop any certain tasks and almost immediately catch the
>>> next
>>> line. So
throw is required to be safe-shield, but
>>> solves not enough
>>> count
>>> of cases.
>>>
>>> Old, maybe 10 years ago, Fowler's article about "errors is not an
>>> exception". He explained why, but recommend to implement own error bag. I
>>> tried few times implement own error bag on production ready code. And
>>> this
>>> is the hell of rewriting full nesting tree and carrying that return
>>> statement to upper level again and again, then you start to get confused,
>>> then you rewrite all return to objects with properties/getters/setters,
>>> then you understand your PHPStorm started to lag because of 70 uses in
>>> class... Better to use global error bag stack that you can enable or
>>> disable for your needs outside function ("in controller", GRASP) or
>>> inside
>>> function directly like old good times $errors[] and if ($errors) { return
>>> null; }
>>>
>>>
>>> вт, 6 февр. 2024 г. в 18:23, Alex Wells <autaut03@gmail.com>:
>>>
>>> > On Tue, Feb 6, 2024 at 3:58 PM Григорий Senior PHP /
>>> > Разработчик Web <
>>> > 6562680@gmail.com> wrote:
>>> >
>>> >> - 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
>>> >>
>>> >
>>> > Is there an existing language that does that, having both exceptions
>>> and
>>> > these silent raise statements?
>>> >
>>>
>>>
>>> --
>>> +375 (29) 676-48-68 <+375296764868> / Mobile - предпочитаемый
>>> способ
>>> связи
>>> https://t.me/gzhegow /
>>> https://t.me/%2B375296764868 / Telegram
>>> 6562680@gmail.com
>>>
>>
>
> --
> +375 (29) 676-48-68 <+375296764868> / Mobile - предпочитаемый способ
> связи
> https://t.me/gzhegow /
> https://t.me/%2B375296764868 / Telegram
> 6562680@gmail.com
>
--
+375 (29) 676-48-68 <+375296764868> / Mobile - предпочитаемый способ
связи
https://t.me/gzhegow / https://t.me/%2B375296764868 / Telegram
6562680@gmail.com