Hi,
The vote is now open for Stream Error Handling Improvements
RFC: https://wiki.php.net/rfc/stream_errors
The vote will close on 2026-05-18 22:00:00 UTC.
Kind regards,
Jakub
Hey Jakub,
Hi,
The vote is now open for Stream Error Handling Improvements
RFC: https://wiki.php.net/rfc/stream_errors
The vote will close on 2026-05-18 22:00:00 UTC.
Kind regards,
Jakub
thank you for your work on this RFC, this isn't a glamorous topic at
all, but a much desired improvement.
I hope everyone shares that sentiment!
Bob
Hello,
thanks for your work on this, really good.
sadly i voted no for the reason i explained, and pushing it as many may
vote for the very good improvements and "ignore" the fundamental design
flaw for the new addition, so I think it will surely pass, but that's kind
of bad. And as you did not add two votes...
best,
Pierre
Hi,
The vote is now open for Stream Error Handling Improvements
RFC: https://wiki.php.net/rfc/stream_errors
The vote will close on 2026-05-18 22:00:00 UTC.
Kind regards,
Jakub
Hi,
Hello,
thanks for your work on this, really good.
sadly i voted no for the reason i explained, and pushing it as many may
vote for the very good improvements and "ignore" the fundamental design
flaw for the new addition, so I think it will surely pass, but that's kind
of bad. And as you did not add two votes...
As I told you many times, the things that you mentioned can be easily added
later without any BC impact - they are not flows but just extra features
that you think should be there. I didn't ignore it, I just don't think what
you proposes is worth adding.
Kind regards
Jakub
Hi Jakub,
Hi,
As I told you many times, the things that you mentioned can be easily
added later without any BC impact -
first of all, and let me remind you to keep your tone respectful. This is
not ok nor reflect the discussion we had here.
they are not flows but just extra features that you think should be there.
I didn't ignore it, I just don't think what you proposes is worth adding.
-
these are not extra features, but core design decisions for new added
exceptions and flow that will remain for a very long time -
yes they can be added later and keep the wrong design in the then old one
all in all, it is not the end of the world. I didn't say you cannot
disagree, quite the contrary. I would have appreciated two votes, that is
all.
best,
Pierre
Hi,
Hi Jakub,
Hi,
As I told you many times, the things that you mentioned can be easily
added later without any BC impact -first of all, and let me remind you to keep your tone respectful. This is
not ok nor reflect the discussion we had here.
The tone was respectful. I just thought it was many times but in fact I
told you just twice so sorry about that "many". I would just assume that it
should be clear that there is no BC concern. Especially my second replay
was quite clear and you never explained the BC concern later:
I don't see how it takes more effort later. There is also pretty much no
BC break even if we went if subclassing exceptions as I noted before. I
think actually exactly opposite here. If we rush it and use incorrect
categories for some errors, it will be a BC break to correct so this needs
a proper considering and this feature should be added later.
I removed classification completely so I have no idea what that second vote
would be about.
Anyway let's agree to disagree here.
Kind regards
Jakub
Hi,
The vote is now open for Stream Error Handling Improvements
The RFC has been accepted with 25 yes, 1 no and 5 abstain votes.
Thanks for voting.
Kind regards
Jakub