Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122323
MIME-Version: 1.0
References: <CAK=iT=UrMCPw5ydCnxa_87ws6xKRO5Y3qJnmchczgDds8u660A@mail.gmail.com>
 <CABigaAUjSx3-vEaQhPk-toJTSg+J3CLrO3otpm1g6hqbYyQKvw@mail.gmail.com>
 <CAK=iT=WgsEZjyu3Y2wTWvycqCsYH7MrLsZgERZK3u75U08ePpA@mail.gmail.com>
 <CAL0xaBHfEMs1BVAMZOuFCUpb9orNSRD0YDhu=3wJAGK7K0_=dg@mail.gmail.com>
 <CAK=iT=XDVcs+y4XDmGu2re137i2yD9LiEj1-HLvyxxxrb8jFUw@mail.gmail.com>
 <CAK=iT=UDUjCZ-25k_MkHFO7uKdWAqoJxdWLVBGM2_SYDk-JyAg@mail.gmail.com>
 <742f202d-7990-4f51-b903-7a15e3fd33c2@app.fastmail.com> <CABigaAW2KeGxf7HnzpcOeS=CL31=UNGZnqpZvoJsJg4miBTBGw@mail.gmail.com>
In-Reply-To: <CABigaAW2KeGxf7HnzpcOeS=CL31=UNGZnqpZvoJsJg4miBTBGw@mail.gmail.com>
	=?UTF-8?B?Yg==?= <6562680@gmail.com>
Date: Wed, 7 Feb 2024 10:25:12 +0300
Message-ID: <CAK=iT=UzhU-5c+g46-nhRc3RaYUrFY+aG2OgMABBd47n5Fa4zA@mail.gmail.com>
To: autaut03@gmail.com, internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000a285490610c59a2c"
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==?=)

--000000000000a285490610c59a2c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 right, but external system doesnt
think so".

Example 1:
i send correctly and valid first name (for my system) to external system.
That system reported thats name contains character outside its regular
expression. I can solve it in-place creating function with regular
expression that change invalid chars to question marks and case will be
covered.

Example 2:
My system result is less than zero. Remote system expects greater than
zero. I cant just validate/sanitize data to greater than zero. If i send
single operation - it could be the exception. But there could be two cases
- multiple operations (commands) queue or bulk operation (one command, few
rows of different data). In first case i have to stop all operation,
exception could help me. In second case same error becomes to warning, and
one row should not stop whole process, but have to report me. So previously
i solved it with exception, and now exception shots my legs. Thats why i
use exceptions only if something wrong on developer/user side, and never to
system-system cases. if() still powerful.

=D1=81=D1=80, 7 =D1=84=D0=B5=D0=B2=D1=80. 2024=E2=80=AF=D0=B3. =D0=B2 03:55=
, Alex Wells <autaut03@gmail.com>:

> On Tue, Feb 6, 2024 at 7:14=E2=80=AFPM Larry Garfield <larry@garfieldtech=
.com>
> 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 be implemented without generics.  (ADTs would be an
> > optional nice-to-have.)  And if the caller doesn't handle DivByZero, it
> > would try to pass it up to its caller, but being checked it would requi=
re
> > the caller to also declare that it can raise DivByZero.
> >
>
> Let's assume that the developer knows the divisor isn't 0 - through an
> assertion or an `if` clause above the call to `divide(5, $divisor)`. In
> this case, DivByZero error cannot ever be thrown (or risen), but the
> developer would still have to either handle the error (which will never
> happen) or declare it as raisable, which in turn may require also marking
> 10+ function/method calls as "raises DivByZero". Both options aren't grea=
t.
>
> And even if there was no assertion about the divisor, maybe the developer=
's
> intent is exactly to ignore that case as an "implicit assertion" - meanin=
g
> instead of explicitly asserting the divisor value themselves (through
> `assert($divisor !=3D=3D 0)`), they rely on `divide(5, $divisor)` doing t=
hat
> implicitly for them. If the `assert()` fails, then nobody is expected to
> really handle that assertion error; it usually bubbles up to the global
> exception handler which takes care of it. If the `divide()` fails on the
> other hand, checked exceptions would require all the callers to actually
> "check" it by catching or declaring the caller function as `raises
> DivByZero`, but this doesn't bring any benefit to the developer in this
> case.
>
> So I assume this is why Java developers hate checked exceptions and why
> Kotlin doesn't have them. I'm not aware of other implementations of check=
ed
> exceptions; there may be other, better versions of them. If you have any =
in
> mind that overcome the issues above, I'd be interested to look into them =
:)
>


--=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

--000000000000a285490610c59a2c--