Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118122
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-713-g1f035dc716-fm-20220617.001-g1f035dc7
Mime-Version: 1.0
Message-ID: <3a4338fc-5767-4b1d-a584-95e2ecb82572@www.fastmail.com>
In-Reply-To: 
 <CAC5V6giM3+WZ2SR-wZbqoH_quypc1ojXNiKWSCucnM30S_TNDg@mail.gmail.com>
References: <982FFD13-6B2C-4A28-8091-886F2F637B86@me.com>
 <CAC5V6giM3+WZ2SR-wZbqoH_quypc1ojXNiKWSCucnM30S_TNDg@mail.gmail.com>
Date: Wed, 29 Jun 2022 11:38:34 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] Exception type hint
From: larry@garfieldtech.com ("Larry Garfield")

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=42251
>   - https://bugs.php.net/bug.php?id=62404
>   - https://bugs.php.net/bug.php?id=67312
>
> 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 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.

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 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 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/