Everything

php

[RFC] Exception type hint

php.internals

Antoine MAKDESSI

4 years ago

Hello,

I am writing to you regarding my issue on php src available here https://github.com/php/php-src/issues/8843 and the request of the creation of an RFC.

I would like to know if, like all the recent improvements of the php 7 & 8 internal engine goes (return type hint, arg type hint, props typehint, etc)
It could be beneficial for the whole ecosystem to have as well exceptions type hint.

framework/libraries could leverage this with internal exceptions classes/interfaces
and devland code could rely on those to better handle (un)predictable code execution leading to exception

I can of course imagine/understand that this may be a deep internal risky feature but felt the need to discuss it, so please feel free to answer or decline this.

Kind regard, cheers!

Antoine,

Guilliam Xavier

4 years ago

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,

--
Guilliam Xavier

Larry Garfield

4 years ago

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/

Dan Ackroyd

4 years ago

Antoine wrote:

> It could be beneficial for the whole ecosystem to have as well exceptions type hint.

Here are my short notes on the topic.
https://github.com/Danack/RfcCodex/blob/master/throws_declaration.md

tl:dr someone probably needs to come up with a strong reason for why
it would be a good thing.

On Wed, 29 Jun 2022 at 17:39, Larry Garfield <larry@garfieldtech.com> wrote:

>
>   We are definitely not ready for that kind of fundamental rethink of how error handling works in PHP.

I dunno. The current model is causing quite a few disagreements and
pain, and you made a good case for how it could be better.

It'd be a huge piece of work, but a better way of handling errors
would be a significant improvement for PHP.

cheers
Dan
Ack

Larry Garfield

4 years ago

On Thu, Jun 30, 2022, at 8:35 AM, Dan Ackroyd wrote:

> Antoine wrote:
>> It could be beneficial for the whole ecosystem to have as well exceptions type hint.
>
> Here are my short notes on the topic.
> https://github.com/Danack/RfcCodex/blob/master/throws_declaration.md
>
> tl:dr someone probably needs to come up with a strong reason for why
> it would be a good thing.
>
> On Wed, 29 Jun 2022 at 17:39, Larry Garfield <larry@garfieldtech.com> wrote:
>>
>>   We are definitely not ready for that kind of fundamental rethink of how error handling works in PHP.
>
> I dunno. The current model is causing quite a few disagreements and
> pain, and you made a good case for how it could be better.
>
> It'd be a huge piece of work, but a better way of handling errors
> would be a significant improvement for PHP.

Oh there's definitely room to improve PHP's error handling, no question.  I just don't know that PHP is, at this time, capable of the "coherent multi-step roadmap so that different features dovetail together to result in more than the sum of their parts" planning that would be required to do it right. :-)

--Larry Garfield

Jeffrey Dafoe

4 years ago

> -----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=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/
>
> --
> 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.

-Jeff

Michał Brzuchalski

4 years ago

Hi Jeffrey,

czw., 30 cze 2022 o 17:41 Jeffrey Dafoe <JDafoe@fsx.com> napisał(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=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/
> >
> > --
> > 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ł Marcin Brzuchalski