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,
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,
On 4.5.2026 23:16:41, Jakub Zelenka wrote:
Hi,
The vote is now open for Stream Error Handling Improvements
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…
Pierre
On Tue, May 5, 2026, 4:19 AM Jakub Zelenka <bukka@php.net> wrote:
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,
On Wed, May 6, 2026 at 11:21 AM Pierre Joye <pierre.php@gmail.com> wrote:
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,
On Wed, May 6, 2026, 4:47 PM Jakub Zelenka <bukka@php.net> wrote:
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,
On Wed, May 6, 2026 at 12:39 PM Pierre Joye <pierre.php@gmail.com> wrote:
Hi Jakub,
On Wed, May 6, 2026, 4:47 PM Jakub Zelenka <bukka@php.net> wrote:
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