Re: [RFC] Stream Error Handling Improvements

On Wed, Nov 19, 2025 at 10:48 AM ignace nyamagana butera < nyamsprod@gmail.com> wrote: > > On Wed, Nov 19, 2025 at 10:45 AM Lynn <kjarli@gmail.com> wrote: > >> >> >> On Tue, Nov 18, 2025 at 7:40 PM Jakub Zelenka <bukka@php.net> 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 >>> >>> Kind regards, >>> >>> Jakub >>> >>> >> The naming of "terminal" is a little confusing to me. Reading the name >> with a bool made me think it was whether or not the CLI was being used, >> which made little sense in the context of stream errors. After reading the >> explanation "Terminal errors are those that prevent an operation from >> completing (e.g., file not found, permission denied). Non-terminal errors >> are warnings or notices that don't stop execution (e.g., buffer >> truncation).", I feel like it might be more clear if this property was >> named after what the result is, perhaps something like "operationBlocked" >> or "operationPrevented". >> > > > I believe these types of issues can be resolved by replacing boolean > values by Enums, hence my suggestion. Enum would be more self explanatory > and would provide better insight on the outcome. I also like Jordi's > suggestion, anything that can help static analysis is the way to go IMHO. > > Best regards, > Ignace > I ended up removing this from my first reply, but an enum was also what I thought of as it wouldn't surprise me if a 3rd state could be introduced: fully prevented, fully executed but with warnings, and partially executed like a buffer truncation. I just don't know enough about the underlying errors/warnings to suggest this as alternative implementation.