Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118146
MIME-Version: 1.0
References: <982FFD13-6B2C-4A28-8091-886F2F637B86@me.com> <CAC5V6giM3+WZ2SR-wZbqoH_quypc1ojXNiKWSCucnM30S_TNDg@mail.gmail.com>
 <3a4338fc-5767-4b1d-a584-95e2ecb82572@www.fastmail.com> <448645c78da44675ac3434df3384f815@fsx.com>
In-Reply-To: <448645c78da44675ac3434df3384f815@fsx.com>
Date: Fri, 1 Jul 2022 07:44:57 +0200
Message-ID: <CABdc3WqtsnDr=6z2yLufN9XFqvH4MKAQ758A-GOELDhgGWpUKw@mail.gmail.com>
To: Jeffrey Dafoe <JDafoe@fsx.com>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000089d60005e2b7e301"
Subject: Re: [PHP-DEV] [RFC] Exception type hint
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=)

--00000000000089d60005e2b7e301
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jeffrey,

czw., 30 cze 2022 o 17:41 Jeffrey Dafoe <JDafoe@fsx.com> napisa=C5=82(a):

> > -----Original Message-----
> > From: Larry Garfield <larry@garfieldtech.com>
> > Sent: Wednesday, June 29, 2022 12:39 PM
> > To: php internals <internals@lists.php.net>
> > Subject: Re: [PHP-DEV] [RFC] Exception type hint
> >
> > On Wed, Jun 29, 2022, at 10:42 AM, Guilliam Xavier wrote:
> > > Hi (note: your message was flagged as spam),
> > >
> > >> https://github.com/php/php-src/issues/8843
> > >
> > > So I understand it as having a "true code" equivalent for the
> > > `@throws` phpDoc comment (similar to type declarations for `@param`
> > > and `@return`)? which would also be checked at run-time?
> > >
> > > Just my 2 cents on that (let's call it "exception specification"):
> > >
> > >   1. IMHO, it shouldn't be mixed in the return type declaration (with
> > > a union-like syntax) but separated and independent (e.g. with a
> > > `throws` keyword, and pipes [or commas] between multiple exception
> > > classes)
> > >   2. AFAIK, Java has it (mandatory to compile for "checked
> > > exceptions", sometimes controversial), C++ used to have it
> > > (runtime-checked) but dropped it (and introduced `noexcept` instead);
> > > I don't know of any dynamic language that has it
> > >
> > > You would also need to define how it plays with inheritance (and
> > > reflection), and what exactly should happen when a function throws an
> > > exception it didn't "declare"...
> > >
> > > PS: I also found some old feature requests:
> > >   - https://externals.io/message/4424
> > >   - https://bugs.php.net/bug.php?id=3D42251
> > >   - https://bugs.php.net/bug.php?id=3D62404
> > >   - https://bugs.php.net/bug.php?id=3D67312
> > >
> > > Regards,
> >
> > Side Note: Please don't top post.
> >
> > On the subject of checked exceptions, I *highly* recommend this writeup
> > from the lead of the Midori language[1].  It's long, but there's a
> section
> > specifically on exceptions (no deep link, just search the page for it)
> that goes
> > into a lot of detail about exceptions, checked exceptions, and the ways
> in
> > which both fail.  It's absolutely worth everyone's time.
> >
> > The summary for the short-timed is that the only way exceptions work,
> from
> > a reliability standpoint, is if they are 1) Rare and 2) Strictly checke=
d
> and 3)
> > Have really good syntactic shorthand support.  And checked exceptions
> > without the other two are a recipe for hell.  Basically, it only works =
if
> > exceptions become an alternate syntax for an Either monad or Go's multi=
-
> > return.
> >
> > Since PHP is a long, long way from there, I don't believe checked
> exceptions
> > would be wise, or even slightly a good idea.  Not until/unless it's don=
e
> as part
> > of a global rethink of error handling that reimagines how exceptions an=
d
> > errors work at a fundamental level.  And that couldn't be done in a BC
> way
> > with the current practice of "I dunno, throw, YOLO" in PHP exceptions, =
so
> > they'd have to be some other, different channel.  We are definitely not
> > ready for that kind of fundamental rethink of how error handling works =
in
> > PHP.
> >
> > [1] http://joeduffyblog.com/2016/02/07/the-error-model/
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
> visit:
> > https://www.php.net/unsub.php
>
> There's also a decent article here
> https://www.artima.com/articles/the-trouble-with-checked-exceptions where
> Anders Hejlsberg discusses the problems he sees with checked exceptions.
>

Thanks for the link it was really interesting to see issues with checked
exceptions based on someone's experiences.

Cheers,
Micha=C5=82 Marcin Brzuchalski

--00000000000089d60005e2b7e301--