Thanks for suggestion about assert() use cases, i know it exists before,
but never used.
Usually if something shouldn't happen i throw exception there, or at least
type control. Its like manual mark for the future - you doing something
wrong, fix it.
Error collection case its about "you're
On 7/2/24 13:43, Ayesh Karunaratne wrote:
Hi Tim,
Now that the RFC is restarted, could you mention some examples in
Georgian that might be good test cases?
I was thinking there might be some good test cases in Turkish, but
couldn't find any. The RFC has examples
> > I see. I'll change mb_ucfirst using titlecase.
>
> Per my comments a month ago on the GitHub issue , I think it is much
> better to use title case for mb_ucfirst() than to use upper case,
> since conversion of the first character to upper case has the effect
> of corrupting text in the
On Tue, Feb 6, 2024 at 7:14 PM Larry Garfield
wrote:
> These two samples *are logically identical*, and even have mostly the same
> performance characteristics, and both expose useful data to static
> analyzers. They're just spelled differently. The advantage of the second
> is that it could
On 2024-02-07 09:08, Larry Garfield wrote:
"The right tool for the job" is indeed the strongest argument for lightweight
exceptions. It's a tool we lack right now.
I'm thinking not of "DB went away" type issues (Exceptions are already fine there), but
"requested product not found." Right
On Tue, Feb 6, 2024, at 7:56 PM, Григорий Senior PHP / Разработчик Web wrote:
> 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
2024年2月7日(水) 4:49 youkidearitai :
>
> 2024年2月7日(水) 2:56 Juliette Reinders Folmer
> :
> >
> > On 6-2-2024 3:40, youkidearitai wrote:
> > > 2024年2月6日(火) 8:33 Tim Starling :
> > >> On 2/2/24 20:27, youkidearitai wrote:
> > >>
> > >> I see. I'll change mb_ucfirst using titlecase.
> > >>
> > >> Per my
Howdy all, haven't posted in ages but good to see the list going strong.
I'd like a little background on something we've long accepted: why
does the serialization format need double quotes around a string, even
though the byte length is explicit?
Example:
s:5:"hello";
All else being equal I
On Tue, 6 Feb 2024 at 22:09, Larry Garfield wrote:
> On Tue, Feb 6, 2024, at 7:18 PM, Arvids Godjuks wrote:
>
> >> To be clear: I really like this concept and have discussed it with
> others
> >> before, using almost exactly this syntax. I have not proposed it
> because
> >> my read of
On Tue, Feb 6, 2024, at 7:18 PM, Arvids Godjuks wrote:
>> To be clear: I really like this concept and have discussed it with others
>> before, using almost exactly this syntax. I have not proposed it because
>> my read of Internals lately is that there's no stomach for more
>> type-centric
> There's been discussion recently about how to deal with incompatibilities
> between different PDO drivers, especially now that we can have subclasses per
> driver. That may be the way to deal with it. I don't have a major opinion
> on the approach, other than all incompatibilities should be
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
2024年2月7日(水) 2:56 Juliette Reinders Folmer :
>
> On 6-2-2024 3:40, youkidearitai wrote:
> > 2024年2月6日(火) 8:33 Tim Starling :
> >> On 2/2/24 20:27, youkidearitai wrote:
> >>
> >> I see. I'll change mb_ucfirst using titlecase.
> >>
> >> Per my comments a month ago on the GitHub issue , I think it is
On Tue, Feb 6, 2024 at 11:19 AM Arvids Godjuks
wrote:
> On Tue, 6 Feb 2024 at 19:14, Larry Garfield
> wrote:
>
> Thank you Larry for this interesting summary - didn't remember there was
> quite a bit a discussion around the topic prior.
>
> I lean on the "we have exceptions, just leave it be"
On Tue, 6 Feb 2024 at 19:14, Larry Garfield wrote:
> On Tue, Feb 6, 2024, at 4:13 PM, Григорий Senior PHP / Разработчик Web
> wrote:
> > 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
On 6-2-2024 3:40, youkidearitai wrote:
2024年2月6日(火) 8:33 Tim Starling :
On 2/2/24 20:27, youkidearitai wrote:
I see. I'll change mb_ucfirst using titlecase.
Per my comments a month ago on the GitHub issue , I think it is much better to
use title case for mb_ucfirst() than to use upper case,
On Tue, Feb 6, 2024, at 2:28 PM, Saki Takamachi wrote:
> Hi Larry,
>
>> I like this proposal. It's a good incremental improvement to PDO. I also
>> agree with rollbackTo(), to avoid confusion.
>
> Thank you, I'm glad to receive your positive feedback.
>
> It is very difficult to implement these
On Tue, Feb 6, 2024, at 4:13 PM, Григорий Senior PHP / Разработчик Web wrote:
> 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
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)
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
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
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
On Tue, Feb 6, 2024 at 4:26 PM Григорий Senior PHP / Разработчик Web
<6562...@gmail.com> wrote:
>
> 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
On Tue, Feb 6, 2024 at 5:26 PM Григорий Senior PHP / Разработчик Web <
6562...@gmail.com> wrote:
> Short answer is yes. Glad to see that personally adapted answer.
>
What are those languages specifically?
On Tue, Feb 6, 2024 at 3:58 PM Григорий Senior PHP / Разработчик Web <
6562...@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,
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
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
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
On Tue, 6 Feb 2024 at 16:39, Arvids Godjuks
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
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)
Hi Larry,
> I like this proposal. It's a good incremental improvement to PDO. I also
> agree with rollbackTo(), to avoid confusion.
Thank you, I'm glad to receive your positive feedback.
It is very difficult to implement these in pdo_odbc because the odbc API does
not support savepoint.
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
32 matches
Mail list logo
