Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118137
To: Larry Garfield <larry@garfieldtech.com>, php internals
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Exception type hint
Thread-Index: AQHYi8VfQCHaCvYe3EC3oqMr0KCHWK1m+48AgAAPlwCAAQvioA==
Date: Thu, 30 Jun 2022 15:41:07 +0000
Message-ID: <448645c78da44675ac3434df3384f815@fsx.com>
References: <982FFD13-6B2C-4A28-8091-886F2F637B86@me.com>
 <CAC5V6giM3+WZ2SR-wZbqoH_quypc1ojXNiKWSCucnM30S_TNDg@mail.gmail.com>
 <3a4338fc-5767-4b1d-a584-95e2ecb82572@www.fastmail.com>
In-Reply-To: <3a4338fc-5767-4b1d-a584-95e2ecb82572@www.fastmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: RE: [PHP-DEV] [RFC] Exception type hint
From: JDafoe@fsx.com (Jeffrey Dafoe)

> -----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
>=20
> 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,
>=20
> Side Note: Please don't top post.
>=20
> 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 sectio=
n
> specifically on exceptions (no deep link, just search the page for it) th=
at goes
> into a lot of detail about exceptions, checked exceptions, and the ways i=
n
> which both fail.  It's absolutely worth everyone's time.
>=20
> The summary for the short-timed is that the only way exceptions work, fro=
m
> a reliability standpoint, is if they are 1) Rare and 2) Strictly checked =
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.
>=20
> Since PHP is a long, long way from there, I don't believe checked excepti=
ons
> would be wise, or even slightly a good idea.  Not until/unless it's done =
as part
> of a global rethink of error handling that reimagines how exceptions and
> errors work at a fundamental level.  And that couldn't be done in a BC wa=
y
> 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.
>=20
> [1] http://joeduffyblog.com/2016/02/07/the-error-model/
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visi=
t:
> https://www.php.net/unsub.php

There's also a decent article here https://www.artima.com/articles/the-trou=
ble-with-checked-exceptions where Anders Hejlsberg discusses the problems h=
e sees with checked exceptions.


-Jeff