Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122320
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>
In-Reply-To: <742f202d-7990-4f51-b903-7a15e3fd33c2@app.fastmail.com>
Reply-To: autaut03@gmail.com
Date: Wed, 7 Feb 2024 02:55:22 +0200
Message-ID: <CABigaAW2KeGxf7HnzpcOeS=CL31=UNGZnqpZvoJsJg4miBTBGw@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000fdd21e0610c026c3"
Subject: Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301
From: autaut03@gmail.com (Alex Wells)

--000000000000fdd21e0610c026c3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 6, 2024 at 7:14=E2=80=AFPM Larry Garfield <larry@garfieldtech.c=
om>
wrote:

> These two samples *are logically identical*, and even have mostly the sam=
e
> performance characteristics, and both expose useful data to static
> analyzers.  They're just spelled differently.  The advantage of the secon=
d
> 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 require
> 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 great.

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" - meaning
instead of explicitly asserting the divisor value themselves (through
`assert($divisor !=3D=3D 0)`), they rely on `divide(5, $divisor)` doing tha=
t
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 checked
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 :)

--000000000000fdd21e0610c026c3--