Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:127240 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 A796F1A00BC for ; Tue, 29 Apr 2025 14:30:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1745936877; bh=02Vv/cBeGt4ygizlZ2WcBtwdR3O5HvITAPU5vYqUo88=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=fHMPijlnfJE8jZkwrPAHcqhkNoD4S/VnR3OCOdmlGrMZ0Ip4/qkfwc95+W/Md8FBM D6jOAlFvSA+0fXODg10gcumvJhwN1N+klqOXhZIC7zNEoAjMeT5ta4SMmzjxk3RadE A9kT1bByKT31nbPWLsXNMYvmOHIMtKJ4zzDHW1C+nViwAg925vWDUI+jREAOyzUKif //W14Id2kMkLE9gcJNfyAk334LiDaLQ9/ranQr88gqeAhVxDtVAo0MkQLFQRBvZLHZ KCyyTockIQtdL4S13VIBWwiUSD77n8sZFEc3lTMJBzf/YQi7g6yuddIpczTT9RkPnI 2DAHeymbqDumQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 3271318007C for ; Tue, 29 Apr 2025 14:27:55 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) (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 ; Tue, 29 Apr 2025 14:27:41 +0000 (UTC) Received: by mail-lf1-f43.google.com with SMTP id 2adb3069b0e04-54c0fa6d455so7785488e87.1 for ; Tue, 29 Apr 2025 07:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745936997; x=1746541797; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1OcsrovLzXOkPokGjHB8WSgHddps6CvM48UqN2bYRuc=; b=SA6PonOOB5FvrWSXY9d04+Pfo8E143pIqfJhLWsEEUmRGQLVd7nk8Gla1oBDWYz3yV ZkULbZCbyh/KgwSqnuZgEeTosuIOqIdangs0kHWoBLD+dN7ZuE3R0uKn8HXG5C8AUGrq T/ODq1KJjNp9WnfkuozWSVw2CGZUg0jwSJq2eDwMQVn9mofiY0WshGLS09jF9rZyjz3Z 8qnXBizcHylaAqanqDfK4t1JC7Y81sC6GOLagXZB+K0qATpWwsCa0xN9qtsk4PAtdNZI OvV0zpoP1KKuZ8iELjLDDi3RqxURWPjSQj/neVqrB+Ktcseb9O5aqu16sLYO30UoujSe TWRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745936997; x=1746541797; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1OcsrovLzXOkPokGjHB8WSgHddps6CvM48UqN2bYRuc=; b=tdXz/BpNVOKq3y0kXLPezguL3CZ8cMwf2DhAFxIFu0rng9f9zKWDguOTkZeXs6exD+ 3vPBm6FrFnX36TU5GYcGcXOb4u+co/aXX6sN4THTr7fQO/b60CzHLjQEGMjr8f4q7miR M6cZHNo8cWWoG5pjgDWP0zb/yBO+tHEssfumFBIVTDdMiGGDHwby7+6axhPBKlhNybpi f4V0VbrxlBU8Y7cWracKL44MXNlNWrCrxr4qmpbEDzxQ9dFbhhaKevzGKfk6qpFjKTBf H0T1d1ARKyHH8O21/N//w7rDNETiAGAYtzvPo+eEISGKwM1Ez3sdEGnn6C7JbxBgzXlU y6jw== X-Forwarded-Encrypted: i=1; AJvYcCXCLBqC6YP/QuusdCEqY9Bp1ABluG3P98Oj6IcMsLODeBPQ5q8w4Q8ZyL2+TBWflnjO4l3Zvn3+47o=@lists.php.net X-Gm-Message-State: AOJu0YzH7rn3O5g6vtTtXoXIS+BWaXTWA4JRA6vceqtTpPEgIhPY1DCe xMVyVHnSEkK0SzaOHdk/J6zioVFz1OgLOQp3QAJMYb88WR40LKI2JjGx1xeqApKFsKjs16YKZqp HK8JK7mTzh2JbyS9hh2vbAkhmgpg= X-Gm-Gg: ASbGncth83GM0xL0S5FMir4d/eNSijDwNFGpcFn1N5HeVvbpr/fzP873mgBjm3qSspo Vu1THEOhkjVbW25c6wEc9rkk1tSJtQ6NGjCSLK0G3HFMbFd8dOrajxexJ43xDf1vVvrHS8MxUrn 5Qx7lbGLx5m1cZReX6krw4Fw== X-Google-Smtp-Source: AGHT+IEsT326zTt1sqvGpPut0PW6x/aRdNVkuPl96wYxNh8Mopn5RIbfW7FuT6Z/D/GDIxV67nuR83Mx/ZfG5isTtOw= X-Received: by 2002:a05:6512:3f12:b0:54b:117b:b54d with SMTP id 2adb3069b0e04-54e9e568194mr1028018e87.56.1745936996796; Tue, 29 Apr 2025 07:29:56 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <39597a9c-6854-40c6-a529-32b2b178cb27@app.fastmail.com> <150fb4df-47a4-4ab3-8edb-13e446b122cc@app.fastmail.com> <8ba39427-bc2d-4c2a-90d8-648371e4f576@app.fastmail.com> In-Reply-To: Date: Tue, 29 Apr 2025 09:29:44 -0500 X-Gm-Features: ATxdqUGbzMqx8rCHedZGwJPe6a1zxLjIaE2CIX-y69hOPR1aUddpVzRJIbh-BwQ Message-ID: Subject: Re: [PHP-DEV] Concept: Lightweight error channels To: Hammed Ajao Cc: Larry Garfield , php internals Content-Type: multipart/alternative; boundary="0000000000007e8f310633eba206" From: mweierophinney@gmail.com ("Matthew Weier O'Phinney") --0000000000007e8f310633eba206 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 29, 2025 at 9:09=E2=80=AFAM Hammed Ajao w= rote: > On Mon, Apr 28, 2025, 1:22=E2=80=AFp.m. Larry Garfield > wrote: > >> On Mon, Apr 28, 2025, at 11:28 AM, Edmond Dantes wrote: >> >> I have already demonstrated how it can be solved without generics. >> Multiple response channels from a function already exist: Normal returns >> and exceptions. Exceptions as currently designed are just very poorly >> suited to the problem space I am describing. >> > >> > If another error channel is introduced, PHP would end up with *two >> > error channels*. >> > This is harder to understand than the Normal returns + Exception >> > channels + Something new. >> > >> > It seems to me that this creates a bigger problem than the one it is >> > trying to solve. >> > >> > Is it possible to avoid creating two error channels and instead design >> > an alternative handling method that would eliminate the drawbacks of >> > the first approach? >> > >> > If the performance issue is solved, are the other two problems really >> > worth such changes? >> > >> > For example, if we follow the philosophy of `RESULT`, we can say >> > that there are two types of exception handling cases: >> > 1. Suppressing an exception immediately at the first level of functio= n >> > call. >> >> Suppressing? You mean fataling. Suppressing implies ignore, which is >> the exact opposite of what I am proposing. >> >> > 2. Stack unwinding. >> >> Given the choice between: >> >> success return + error-return + the-world-is-broken >> >> vs >> >> success return + the-world-is-broken + >> the-world-is-broken-but-not-really-so-you-have-to-handle-it >> >> The first seems substantially better, frankly. >> >> Exceptions that are sometimes checked and sometimes not is Java, which i= s >> exactly why everyone hates Java's exception system. >> >> > ```php >> > >> > function someFunction(): string raises SomeException { >> > >> > throw SomeException() >> > } >> > >> > // The backtrace is not generated: >> > >> > $res =3D try someFunction() catch (SomeException) null; >> > >> > // The backtrace is generated when throw $err executed. >> > >> > $res =3D try someFunction() catch ($err) {throw $err}; >> > >> > // The backtrace is generated >> > >> > $res =3D someFunction(); >> > >> > ``` >> > >> > This kind of behavior doesn=E2=80=99t break BC, right? At the same ti= me, it >> > allows improving PHP performance and adding contracts. >> >> The particulars there in that syntax imply the only catch handling would >> be defining a different value, which may not be the desired handling. >> >> Also, that again runs into "throw may be checked or not, you don't alway= s >> know." >> >> It also means the exception is carrying around the extra design baggage >> of exceptions. Even if the trace is elided, it's still carrying useless >> metadata that would lead people astray. It also means dealing with the >> constructor of Exceptions, which is notoriously annoying for extending. >> >> "Make exceptions nicer" is fundamentally not what I am proposing, nor >> will I propose as a solution for this space. It is the wrong approach. >> (Making exceptions nicer is well and good in its own right, and I won't >> block that, but it does not address this problem space.) >> >> It's clear you do not support what I am proposing. Good to know, >> thanks. I still haven't gotten any feedback from major voters, though, = so >> leaving this thread open. >> >> --Larry Garfield >> > > > I fail to see the value in this, seems to be solving a problem I've never > encountered. Who cares what baggage exceptions carry? They are meant for > exceptional situations, seems like you're trying to transform exceptions > into something entirely different under the guise of improving them. > > Two rules I try to consider when it comes to exceptions: * Exceptions are expensive computationally, because they trigger a backtrace on instantiation. * Exceptions should not be used for normal application logic flow. If the "error" is recoverable and/or expected, use a different mechanism so you can use standard conditional branching. As such, there are a lot of situations where I may not want to use exceptions. Two common ones: * Input validation. In most cases, _invalid input is expected_, and a condition you will handle in your code. Exceptions are a really poor mechanism for this. * "Not found" conditions, such as not finding a matching row in a database or a cache. Again, this is expected, and something you should handle via conditionals. Currently, there's no _generic_ way to handle these sorts of error conditions from functions. You can create "result" types specific to each operation, but this is a lot of boilerplate. You can resort to exceptions, but these are a poor fit due to performance and logic flow. I'm currently not yet convinced on the proposal Larry is making, but I definitely understand what's driving it, and would love a language-level solution. --=20 Matthew Weier O'Phinney mweierophinney@gmail.com https://mwop.net/ he/him --0000000000007e8f310633eba206 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Apr 29,= 2025 at 9:09=E2=80=AFAM Hammed Ajao <hamiegold@gmail.com> wrote:
<= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Apr 28, 2025, 1:22=E2=80=AFp.m= . Larry Garfield <larry@garfieldtech.com> wrote:
On Mon, Apr 28, 2025, at 11:= 28 AM, Edmond Dantes wrote:
>>=C2=A0 I have already demonstrated how it can be solved without gen= erics.=C2=A0 Multiple response channels from a function already exist: Norm= al returns and exceptions.=C2=A0 Exceptions as currently designed are just = very poorly suited to the problem space I am describing.
>
> If another error channel is introduced, PHP would end up with *two > error channels*.
> This is harder to understand than the Normal returns + Exception
> channels + Something new.=C2=A0
>
> It seems to me that this creates a bigger problem than the one it is <= br> > trying to solve.=C2=A0
>
> Is it possible to avoid creating two error channels and instead design=
> an alternative handling method that would eliminate the drawbacks of <= br> > the first approach?=C2=A0
>
> If the performance issue is solved, are the other two problems really =
> worth such changes?=C2=A0
>
> For example, if we follow the philosophy of `RESULT<X>`, we can = say
> that there are two types of exception handling cases:
>=C2=A0 1. Suppressing an exception immediately at the first level of fu= nction
> call.

Suppressing?=C2=A0 You mean fataling.=C2=A0 Suppressing implies ignore, whi= ch is the exact opposite of what I am proposing.

>=C2=A0 2. Stack unwinding.

Given the choice between:

success return + error-return + the-world-is-broken

vs

success return + the-world-is-broken + the-world-is-broken-but-not-really-s= o-you-have-to-handle-it

The first seems substantially better, frankly.

Exceptions that are sometimes checked and sometimes not is Java, which is e= xactly why everyone hates Java's exception system.

> ```php
>
> function someFunction(): string raises=C2=A0 SomeException=C2=A0 =C2= =A0{
>
>=C2=A0 =C2=A0 =C2=A0throw SomeException()
> }
>
> //=C2=A0 The backtrace is not generated:
>
> $res =3D try someFunction() catch (SomeException) null;
>
> // The backtrace is generated when throw $err executed.
>
> $res =3D try someFunction() catch ($err) {throw $err};
>
> // The backtrace is generated
>
> $res =3D someFunction();
>
> ```
>
> This kind of behavior doesn=E2=80=99t break BC, right?=C2=A0 At the sa= me time, it
> allows improving PHP performance and adding contracts.

The particulars there in that syntax imply the only catch handling would be= defining a different value, which may not be the desired handling.

Also, that again runs into "throw may be checked or not, you don't= always know."

It also means the exception is carrying around the extra design baggage of = exceptions.=C2=A0 Even if the trace is elided, it's still carrying usel= ess metadata that would lead people astray.=C2=A0 It also means dealing wit= h the constructor of Exceptions, which is notoriously annoying for extendin= g.

"Make exceptions nicer" is fundamentally not what I am proposing,= nor will I propose as a solution for this space.=C2=A0 It is the wrong app= roach.=C2=A0 (Making exceptions nicer is well and good in its own right, an= d I won't block that, but it does not address this problem space.)

It's clear you do not support what I am proposing.=C2=A0 Good to know, = thanks.=C2=A0 I still haven't gotten any feedback from major voters, th= ough, so leaving this thread open.

--Larry Garfield


I fail to see the value in this= , seems to be solving a problem I've never encountered. Who cares what = baggage exceptions carry? They are meant for exceptional situations, seems = like you're trying to transform exceptions into something entirely diff= erent under the guise of improving them.

<= /div>
Two rules I try to consider when it comes to excepti= ons:

* Exceptions are expensive computationally, b= ecause they trigger a=C2=A0backtrace on instantiation.
* Exceptio= ns should not be used for normal application logic flow. If the "error= " is recoverable and/or expected, use a different mechanism so you can= use standard conditional branching.

As such, ther= e are a lot of situations where I may not want to use exceptions. Two commo= n ones:

* Input validation. In most cases, _invali= d input is expected_, and a condition you will handle in your code. Excepti= ons are a really poor mechanism for this.
* "Not found"= conditions, such as not finding a matching row in a database or a cache. A= gain, this is expected, and something you should handle via conditionals.

Currently, there's no _generic_ way to handle t= hese sorts of error conditions from functions. You can create "result&= quot; types specific to each operation, but this is a lot of boilerplate. Y= ou can resort to exceptions, but these are a poor fit due to performance an= d logic flow.

I'm currently not yet convinced = on the proposal Larry is making, but I definitely understand what's dri= ving it, and would love a language-level solution.

--
--0000000000007e8f310633eba206--