Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:127239 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 272321A00BC for ; Tue, 29 Apr 2025 14:07:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1745935496; bh=0k/WjMosBxrFWZNt6bqHFywejRRNOQgAdUtK10EfDmE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=fwDFj0jGkNM5tPWs6VP1zAqy50/vzKOqPcSaa5MB/WQgl2VaxYoj/sPI3TdaetGq/ c+Lwe1f2nG6tXnnTSJFy0MgxK4EXRyB0y0B/3xUB2ZrI7ofB3z5oiOcRAhr+MZWXmh bHdXiq4Wdn8nCt0dlEjL2SAwtr2NSl+Kff8rofGKI9T4ZPGxPBDP0NJNiYUqPIUHxK vk7wIMi4AGmh5MOQiT0uY8YVTK0QK2EGwaZUDjlOcq3e8ig76NSTer7lEBv2bVvCAL memd3k3GYn8unOVqp4votVT+CaSS3TmGB05RTkP6SnFWS6uc7LbmSK6Wp3z6skrHG9 I83EmaSaOKiUw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 24C5B180047 for ; Tue, 29 Apr 2025 14:04: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_H3,RCVD_IN_MSPIKE_WL, 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-oo1-f52.google.com (mail-oo1-f52.google.com [209.85.161.52]) (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:04:51 +0000 (UTC) Received: by mail-oo1-f52.google.com with SMTP id 006d021491bc7-6021e3daeabso3163207eaf.3 for ; Tue, 29 Apr 2025 07:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745935628; x=1746540428; 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=wD5OeHO59aCaAwpSAYdPxsPNi1naW7iPgkY8FCumBJY=; b=Kx9d+nEgIbUbgj+PM8XfKCvwUCiUe5hGGBqSfI+K9it6JqYuYzcVMmBTOwEZtlUaws /cOdj5al9pZ1mf9mtDZSDIts8/nkHtKkfICqei2EbHA1cqjHnVMQOl7cdeKQm8+kmEuZ QYM0yBNfyvYtvf/9awhNtYa8zqRtfM0X1mkawaRlKNmJAQkDA+19NzMWiGCfzRgtol0g wN8OgdOfuaQcvWzM+YIQ4P5nF3vBRjoIeNCBM61mQRLU3jl6nVayDxvKBdxvyCHHcOaK ti7Q7FBvv3uJrEgwP1h6+QNcJ6cUoe35Lv2az0mjVp62k+GOV+jxabsJEGgc7SPSod4h g+YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745935628; x=1746540428; 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=wD5OeHO59aCaAwpSAYdPxsPNi1naW7iPgkY8FCumBJY=; b=ZBZThseq3LExV0M6RmFUe3N4GU+UGmM36xqaF+tN6c/xwgFmUs8mYokF7dMOTaBIfZ bAyEalm6XfiWsEEqGZt6LgrgPegoP3TCD80VmY06+qiOhNyC+rYOYuLA7uNzPCOS0efo 5iEDK4FFXVZToxDEwvcwyfFbwHkp2DI09AiGihd6tjgKp+dNzQNgW4OftEVI+QNxx8kA 91vsNEkGPaDaiNxr3OxLFVkwYepbLnIgKE8UwBdbPRC5/Z+dLfEHUjEg2iEuXnbYSYCh /scUHoSvhXdlxg8XohEkSvz9Q4jESEv0rB2q3wrC1ioGZbA16zgjI8Ao9fUINfJcCPig McCg== X-Gm-Message-State: AOJu0YznrvjqG+ux4RqjsJRtb0qC1cE4RWC/+M8C/pAaVHTLK9hiFAOK LQ/0cEWk7klgKt82WxKkBCt5pJrpVjyyViIef2XsDN+av8WENdCHzX16h1Z8yYJbUxPY2tmA7dy vz2c5r+0GSndvtEZYjoLx5ubgLwJwAw== X-Gm-Gg: ASbGncsSUqsTf4tyrjM+TP/Om/CwfABKGGStjoPh6cPOEO7/MUmq3niGUBRkWX+I7uw 9Nwy5+Lk5vUIyCVQgW2KXuW70sSQRoNxTmmoh3Q5mEr7StTocSqcw4ehasLLhuePG76v1s676H1 qXN+swIas4nKZ7M0HGXMCYpQkoK9lm/0YMq/HROYSX2kLAFX9gQfFCYJgP X-Google-Smtp-Source: AGHT+IHjAAdSGlcWWCTN2RAWMbMzaEub5fJy4EOqE/6ChI6krJs4gF55BCnlf9O+vyHvFmRQAL3ylX7qNBGQW9BfaYM= X-Received: by 2002:a05:6820:1885:b0:604:5e57:80ab with SMTP id 006d021491bc7-60685b70ccdmr1400478eaf.0.1745935627625; Tue, 29 Apr 2025 07:07:07 -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: <8ba39427-bc2d-4c2a-90d8-648371e4f576@app.fastmail.com> Date: Tue, 29 Apr 2025 08:06:56 -0600 X-Gm-Features: ATxdqUEYANR0K9I_BYRRSOoU4CKqxGetblwZhlP9ZpaNyfuhQKmYAB4AvdmDT60 Message-ID: Subject: Re: [PHP-DEV] Concept: Lightweight error channels To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="000000000000e2a7990633eb50d3" From: hamiegold@gmail.com (Hammed Ajao) --000000000000e2a7990633eb50d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 function > > call. > > Suppressing? You mean fataling. Suppressing implies ignore, which is th= e > 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 is > 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 tim= e, 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 o= f > 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 wil= l > I propose as a solution for this space. It is the wrong approach. (Maki= ng > exceptions nicer is well and good in its own right, and I won't block tha= t, > 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. - Hammed > --000000000000e2a7990633eb50d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 dir=3D"auto">- Hammed
--000000000000e2a7990633eb50d3--