Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129307 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id C47861A00BC for ; Wed, 19 Nov 2025 15:38:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1763566742; bh=3IsgMraRr36zJTob050olfuCWccJEze6+KV6Vux0Ayo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=BnZDCOxU/Z558oPFOy1tLCiDlAMYPlerzE3C8PHcBinz/roPV9DAXfGQ22dC1R/xj 89s+2ZXTkwy8yEwV0Iv1DE2nkpA/fDwvWG3QXLpkq9TGxNVMc3YT9IC6LywGBwadKU mQrh4mu2UCppIMUmRunrvxJ1NyGkRoRC51uNUc64H66YRrh2ClegzuJol6Nk6injek C6p+EksciARyrVsXebwnFmkf11v6+e2GXK3ceg9VUgHFJR4wNvkxxX88+gjq+WrmJJ iDLS6mN7jO6kJEXKGt6GkIPygdnM57h/xwthduJCHg9Z2jz+O9lhyG6WqF15iDEwXQ FD8ffH2ov7giQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 4DD3B1801D7 for ; Wed, 19 Nov 2025 15:39:01 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=BAYES_50,DMARC_NONE, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 19 Nov 2025 15:39:01 +0000 (UTC) Received: by mail-ot1-f47.google.com with SMTP id 46e09a7af769-7c75fd8067fso2134245a34.2 for ; Wed, 19 Nov 2025 07:38:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763566735; x=1764171535; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=//MmpjMj4nKRk/pPObLIVn1ec1kB3TERfuHeJzGdxTY=; b=jNb6jTJd9AxXqxj+dp+ssEh+OZ4Xaf6T0LQrYiqDeRAASRSCeTFsPSBMQ/uGypHKYo RJNCgIQ9hEJz1K2POethtb2wJbgdxm3ZZxa5zIkLaoky661xx+pItHejeH/BMUiZowDH iz/zTKfyrV4BNLBrmMs/x4Ss/+w7mACqzGM7DyFKeiP1aKjRboBt9vTr0V/3X2RAcuSq 3Lokkhnn9bU0cai1yzX5vZOBOYCXhHuJy3unJI66o9ugvWvPxNoWVyzr9cnlSvqqyTLX yGRO1rvc9IHN8gMwd+s0pErFTT5M1araJbueix+88ktIC2ZnZ6HNnRRGLz3BI0mwuukj IO3g== X-Gm-Message-State: AOJu0YwXHgMJ4W9TCtvvqOCI2RejrdcHQ3BTsvvNaI1v7miL7+ltPWjO I7WOk1uBgFEZbCSypovz69kmNziC5PmmuKTlU2sQHBsZlc2WHZ2KI7XR/8nWLNrvCX4m2ZQcF57 Qxc+PjZXomxowcRbbbSdGHfjzLOb8WYVUEF9vaeI= X-Gm-Gg: ASbGncuGf6O0SObQYpYs6wrexVg65NUvN01aszHf8HFY52tmC1O4EWFgj2rj1XVKl/G zNCFkxKNnL67LIkwlDLw1qef362qT+uvEKMGjNtXLQVv/FVMsIxjCKzWosHjdkpfUu7PFXQnivH PXpprt1XPhBiL/hU/hb1tpfEDAMOm4lF/K8t+6liZSskErKH0PRLDGexRpNYcFK3TEvEshg8Vbg tEspBI3OiTQ1Pm39hkrjM0qAEmAGO1km8Nhn2IWBGf/hCTaHZ5k8YII1KjirvH9CmS0+Q== X-Google-Smtp-Source: AGHT+IF3wEiqalyF9qtpCIe6LIuH0SCVAgZQoWqMzoQOhmRIV8a7TPriHjFM99rJhC2UhBI6TGbT0rud/eKsvWk3VsM= X-Received: by 2002:a05:6870:fb94:b0:3d4:3:6548 with SMTP id 586e51a60fabf-3e869165096mr11615897fac.45.1763566735233; Wed, 19 Nov 2025 07:38:55 -0800 (PST) Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 19 Nov 2025 16:38:43 +0100 X-Gm-Features: AWmQ_bnAyeUp5-ni5_JRh8mpIKdvJX06HcaOmR4JEe-ahTzyGcvs93QkLVH5PUk Message-ID: Subject: Re: [PHP-DEV] [RFC] Stream Error Handling Improvements To: "Gina P. Banyard" Cc: PHP internals list Content-Type: multipart/alternative; boundary="000000000000ca95d30643f46080" From: bukka@php.net (Jakub Zelenka) --000000000000ca95d30643f46080 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Gina, On Wed, Nov 19, 2025 at 12:14=E2=80=AFPM Gina P. Banyard wrote: > On Tuesday, 18 November 2025 at 18:41, Jakub Zelenka > 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 o= f > 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? > > I just answered this in replay to Bob. The non terminating errors are those that don't change return value of the function (it means not returning failure). Some of those errors are still useful and users should be notified but they are not critical for correct result. This was mainly introduced for exceptions as those cases should not throw but it still makes sense to somehow notify users (e.g. store the error). > How does this interact with the stream notification stuff? > (I guess surrounding PHP_STREAM_NOTIFY_SEVERITY_INFO and > PHP_STREAM_NOTIFY_SEVERITY_ERR) > > It doesn't interact with it. Although PHP_STREAM_NOTIFY_SEVERITY_ERR somehow overlaps with it but it's limited in use (currently used only in ftp and http wrapper). Obviously I couldn't just use notifications and I needed to keep them working so the only possibility was to introduce a new API that handles just errors. Going forward I'm not sure PHP_STREAM_NOTIFY_SEVERITY_ERR should be kept but that's more a future scope I guess. > 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 applicabl= e > 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. > > Agreed I'm not going to expose it. I will keep it just for error mode to keep it the same but I guess it might be better to drop it completely in the future. > The last thing that I feel *very* strongly about is that there should onl= y > 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". > > My aim is really not to touch the current logic and the error classification except one case where reporting was done accidentally. I think that non terminating errors make some sense as they give some hint that something could be improved but it's not necessarily preventing the functioning. This is something that has been already there and I don't think it needs to be changed as part of this proposal. Cheers, Jakub --000000000000ca95d30643f46080 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Gina,

On Wed, Nov= 19, 2025 at 12:14=E2=80=AFPM Gina P. Banyard <internals@gpb.moe> wro= te:
On Tuesday, 18 November 20= 25 at 18:41, Jakub Zelenka <bukka@php.net> wrote:
Hello,

I would like to introduce a new stream error handlin= g RFC that is part of my stream evolution work (PHP Foundation project fund= ed by Sovereign Tech Fund) :

https://= wiki.php.net/rfc/stream_errors

Hi Jakub,

Thank you for working on this, this has been a long-standin= g pain point of our stream layer.
However, I do have various comm= ents about the design of this.

Echoing multiple vo= ices, please use enums rather than constants where applicable, and use an o= bject rather than an associative array for individual stream errors.
<= div>As others have pointed out, the notion of (non-)"terminal" er= rors is not clear, and I'm struggling to understand what is the point o= f it?


I just ans= wered this in replay to Bob. The non terminating errors are those that don&= #39;t change return value of the function (it means not returning failure).= Some of those errors are still useful and users should be notified but the= y are not critical for correct result. This was mainly introduced for excep= tions as those cases should not throw but it still makes sense to somehow n= otify users (e.g. store the error).
=C2=A0
How does this interact with the=C2=A0stream notification stuff?
(I guess surrounding=C2= =A0PHP_STREAM_NOTIFY_SEVERITY_INFO=C2=A0and=C2=A0PHP_STR= EAM_NOTIFY_SEVERITY_ERR)


It doesn't interact with it. Although=C2=A0PHP_S= TREAM_NOTIFY_SEVERITY_ERR somehow overlaps with it but it's limited in = use (currently used only in ftp and http wrapper). Obviously I couldn't= just use notifications and I needed to keep them working so the only possi= bility was to introduce a new API that handles just errors. Going forward I= 'm not sure=C2=A0PHP_STREAM_NOTIFY_SEVERITY_ERR should be kept but that= 's more a future scope I guess.
=C2=A0
Regarding "docref" what is the p= oint 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 exi= sts in doc-en, this does not seem applicable here.
I guess you ad= ded this due to the two usages of "streams.crypto" a= s a docref in=C2=A0main/streams/transports.c, but= this ID doesn't exist, and I fear this might never have worked properl= y.
As such, I would recommend just getting rid of this.


Agreed I'm not going = to expose it. I will keep it just for error mode to keep it the same but I = guess it might be better to drop it completely in the future.
=C2= =A0
The last thing t= hat 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 not= ice 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=C2=A0main/streams/userspace.c)
And the singular cas= e which bailouts using E_ERROR should be converted to always throw an excep= tion.
Bailouts cause all sorts of issues due to the lack of unwin= ding, things that exceptions solve.
This would also simplify both= the internal, and userland API and get rid of the confusing notion of &quo= t;errors" meaning "diagnostics/warnings".

My aim is really not to= touch the current logic and the error classification except one case where= reporting was done accidentally. I think that non terminating errors make = some sense as they give some hint that something could be improved but it&#= 39;s not necessarily preventing the functioning. This is something that has= been already there and I don't think it needs to be changed as part of= this proposal.=C2=A0
=C2=A0
Cheers,
Jakub
--000000000000ca95d30643f46080--