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,
Hi (note: your message was flagged as spam),
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"):
- IMHO, it shouldn't be mixed in the return type declaration (with
a union-like syntax) but separated and independent (e.g. with a
throwskeyword, and pipes [or commas] between multiple exception
classes) - AFAIK, Java has it (mandatory to compile for "checked
exceptions", sometimes controversial), C++ used to have it
(runtime-checked) but dropped it (and introducednoexceptinstead);
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
Hi (note: your message was flagged as spam),
So I understand it as having a "true code" equivalent for the
@throwsphpDoc 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"):
- IMHO, it shouldn't be mixed in the return type declaration (with
a union-like syntax) but separated and independent (e.g. with a
throwskeyword, and pipes [or commas] between multiple exception
classes)- AFAIK, Java has it (mandatory to compile for "checked
exceptions", sometimes controversial), C++ used to have it
(runtime-checked) but dropped it (and introducednoexceptinstead);
I don't know of any dynamic language that has itYou 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.
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.
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
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.mdtl:dr someone probably needs to come up with a strong reason for why
it would be a good thing.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
-----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 hintHi (note: your message was flagged as spam),
So I understand it as having a "true code" equivalent for the
@throwsphpDoc 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"):
- IMHO, it shouldn't be mixed in the return type declaration (with
a union-like syntax) but separated and independent (e.g. with a
throwskeyword, and pipes [or commas] between multiple exception
classes)- AFAIK, Java has it (mandatory to compile for "checked
exceptions", sometimes controversial), C++ used to have it
(runtime-checked) but dropped it (and introducednoexceptinstead);
I don't know of any dynamic language that has itYou 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/
--
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
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 hintHi (note: your message was flagged as spam),
So I understand it as having a "true code" equivalent for the
@throwsphpDoc 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"):
- IMHO, it shouldn't be mixed in the return type declaration (with
a union-like syntax) but separated and independent (e.g. with a
throwskeyword, and pipes [or commas] between multiple exception
classes)- AFAIK, Java has it (mandatory to compile for "checked
exceptions", sometimes controversial), C++ used to have it
(runtime-checked) but dropped it (and introducednoexceptinstead);
I don't know of any dynamic language that has itYou 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/
--
To unsubscribe,
visit:
https://www.php.net/unsub.phpThere'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