Re: Re: [RFC] Stream Error Handling Improvements

Hi thank you for your RFC. I'm regretfully late to the party, but my primary comment about the RFC relates to the latest changes. Specifically: Am 2026-02-27 23:21, schrieb Jakub Zelenka:

I changed it to the StreamError class constants and also move the is*Error functions there.

The RFC specifically defines “ranges” for the numeric value of the error constants, some of which are quite small with only 10 values available. I believe this is dangerous, because it is possible to run out of values within a specific range and users might make assumptions based on the ranges when they really should rely on the is*() methods to check what type of error there is. This is not a problem that would exist if the error code was an unbacked enum. Contrary to Nicolas, I also don't think it is a problem for the error code enum to be extended in future PHP versions. In other programming languages, Rust specifically, it is also common for errors to be defined as an enum that is explicitly defined to not be exhaustive. Here's an example in the standard library: https://doc.rust-lang.org/std/io/enum.ErrorKind.html. Note how the documentation says:

In application code, use match for the ErrorKind values you are expecting; use _ to match “all other errors”.

And the same would be possible in PHP by using a default branch in a match() expression. We could also add a “NonExhaustiveEnum” interface (or attribute) to PHP as a helper indicator for static analysis tools to warn if a default match is missing. -------- As for the StreamError class being a linked list: I agree with the folks that mentioned that the returned errors should be an array instead. count() would naturally be available, hasCode() can be implemented with `array_any($errors, fn ($error) => $error->code === CODE_DECODING_FAILED)` and the “primary error” can be obtained with array_first() (which we added in PHP 8.5). For the naming of stream_get_last_error(): Within PHP we have both X_get_last_error() and X_last_error(). The latter seems to be more common and also what I would prefer here, because the stream_get_ prefix sounds to me like we would get something from a stream, but the returned value is not related to a specific stream, but rather a global. Best regards Tim Düsterhus