Re: [RFC] Stream Error Handling Improvements

Hi, On Wed, Nov 19, 2025 at 10:57 AM Lynn <kjarli@gmail.com> wrote: > > > 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. > I don't think we will add another state. The enum based approach seems most reasonable to me. I should also change the name terminal / non terminal to terminating / non terminating as I think that's the correct name for this.... Cheers, Jakub