On Tuesday, 18 November 2025 at 18:41, Jakub Zelenka <[email protected]> wrote:
> Hello, > > I would like to introduce a new stream error handling RFC that is part of my > stream evolution work (PHP Foundation project funded by Sovereign Tech Fund) : > > https://wiki.php.net/rfc/stream_errors Hi Jakub, Thank you for working on this, this has been a long-standing pain point of our stream layer. However, I do have various comments about the design of this. Echoing multiple voices, please use enums rather than constants where applicable, and use an object rather than an associative array for individual stream errors. As others have pointed out, the notion of (non-)"terminal" errors is not clear, and I'm struggling to understand what is the point of it? How does this interact with the stream notification stuff? (I guess surrounding PHP_STREAM_NOTIFY_SEVERITY_INFO and PHP_STREAM_NOTIFY_SEVERITY_ERR) Regarding "docref" what is the point of including this in the error? This is mainly used with php_docref to generate links to INI settings by referencing an XML ID that exists in doc-en, this does not seem applicable here. I guess you added this due to the two usages of "streams.crypto" as a docref in main/streams/transports.c, but this ID doesn't exist, and I fear this might never have worked properly. As such, I would recommend just getting rid of this. The last thing that I feel *very* strongly about is that there should only be 3 modes: - Silent - Warnings - Exceptions As such, the cases where we currently emit a notice should either be promoted to warnings (which for some of them I don't even understand why they are just notices) or removed (mainly looking at the one in main/streams/userspace.c) And the singular case which bailouts using E_ERROR should be converted to always throw an exception. Bailouts cause all sorts of issues due to the lack of unwinding, things that exceptions solve. This would also simplify both the internal, and userland API and get rid of the confusing notion of "errors" meaning "diagnostics/warnings". Best regards, Gina P. Banyard
