Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:127221 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 qa.php.net (Postfix) with ESMTPS id 234321A00BC for ; Mon, 28 Apr 2025 12:40:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1745843899; bh=A5J0Jdq/v3tKf0ixt+ZIS/IKKzuF7Bu6ZaIPyOmxvwk=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=ZCDkvCZm0tt5WpRN+Q45JGpFiE2AsIXpBeTGl1XMKyQtXkcdWGbUJN3rsPupYwBqI AFrHLaI/Xr6FgdjBqEgaWt67kELw0hlBBKfeBN1ZKPqMULWLzrUQrMuubJBZLONSSZ trIQzc8Y++h0N6edaLwD3fAyaRLIdfoZSWIIEUtVOcnnNOO/nIPzldo/G+Q3RQoxtt hyCumh1kpkAk2fLE0ZlnJh+C2Ekwqw+yOR84YnGqUR3IBSNlbzZnrnASjWgshYd0ld aMhYD3qw05bsGzCbHn/umKfqvwDP3ABvWc8lPfkFQm02M6B+POEZr3z8sLwdJuhFUa 9yQQX7Sq1TA0Q== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 9E433180068 for ; Mon, 28 Apr 2025 12:38:18 +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_MISSING,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 mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 28 Apr 2025 12:38:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasbley.de; s=s1-ionos; t=1745844029; x=1746448829; i=mails@thomasbley.de; bh=dNA7USR/vnv70rKqXv6v9h3sUiGrbpYftSTRT2B0c18=; h=X-UI-Sender-Class:Date:From:To:Cc:Message-ID:In-Reply-To: References:Subject:MIME-Version:Content-Type:cc: content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=ynOj7br9rn5bVa8SyWtMtZho+pc78/lI4XCkuOY3u3CvyJFTSYsAnrOza0tSScxJ TAs0Eimhc8VSRzY0S+kscP1q8JwA6flhy4QxDX2VkuAgfV0myHzZ5+LO8tLmI+KYM 9MrV7m6KKoWOztWbjw6zGF1X0CeiimNlXvXaAXN6KFAbor+FdDr/Uq5wtnPnzWBJC BTBWVlpjKhXbCf4hsyQeC//mprT8/sFZ0wHdazB+vq/rnGVUvqh2GLhGwfxdqjhp4 E6/yIkXFm0aXi5q3K0U5uEx6AaikJUxlOp992cxG9LhYTvIpsWuJ1I7scvUHa/yXm +Mn4zEYPx0zc7Zyn/g== X-UI-Sender-Class: 55c96926-9e95-11ee-ae09-1f7a4046a0f6 Received: from open-xchange-core-mw-default-16.open-xchange-core-mw-hazelcast-headless.open-xchange.svc.cluster.local ([10.73.156.250]) by mrelayeu.kundenserver.de (mreue011 [172.19.35.3]) with ESMTPSA (Nemesis) id 1Mum2d-1uzQ8k2pnf-010BH1; Mon, 28 Apr 2025 14:40:29 +0200 Date: Mon, 28 Apr 2025 14:40:29 +0200 (CEST) To: Edmond Dantes , Larry Garfield Cc: php internals Message-ID: <1748435831.865240.1745844029113@email.ionos.de> In-Reply-To: References: <39597a9c-6854-40c6-a529-32b2b178cb27@app.fastmail.com> Subject: Re: [PHP-DEV] Concept: Lightweight error channels Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_865239_1169202253.1745844029107" X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v8.33.58 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:oLhKs+52EjYd/joXMNyqIRnHugpzZ0yIbxHhay5I0lZMtfUo6uh V88g2CBMcrHYlQdjt3dV8aupjPT3/zTLcjtlu47y7LiUw29/ocVFw5sXOKmkT13IrmsXQHX ChlfZCuDyXvuB6Ik0V/uZ5RLkiELSElxJiz+qPCE7FIAqDa1MqoUrN6xrlqcEqVnhqcagqj spZo7ECKvUjRv/p+MoF8Q== UI-OutboundReport: notjunk:1;M01:P0:oA5J486gRkU=;3oOOHR177W7nxNZEB5NCk2fLFQr F7lUek0F6bWjernFhetl/rVA0PS6XhkR9to8txlldSPUtz4nlosW7eDSYudM8zDfrwjv+jVVG qe8vACIvwViJP/wyk6NkkCsOWEkewRTLuPr+VqKn5VOP1OvYyFg9M2E+yx/UjI8MDvfYmybDP vXoqj3RUbjjsQMrRp0EjPz5X7p8vzyWB9w9VrPUhi6qfDGsODQKTANTBy0tb7R9hTfPoXiCqu 6C6h9VciXjtA+754bT9LULOQhfuQahAFLdYtv1iE41G2B7/gWXHei8Yj8b1r6H8WjfBokJCbb dTSDkStqifV6jlDgVTBPMC/1DrJWioUqjzwcfEdo9UnWwR8fXErpLCFZcvldsZVwEMYwMw9ZZ k90wtMOYvvhkj4ZXNyv4K+pFxgmtkVJp2UwfooHMoH58hZiQ5DsyULx4yR+Y4mbnXSRepmFM0 8UTn0i5/U6ixnW4fEWR90L8lu9xlHihqjCsJv6F66wC4lh3PaC21avgESrhaEN+3L181yS5vd Hzjnn33AVeFYYGbs4v/UMK/ruNGZyTKBHc0liWtrn4qjPH/1sPryP4Y8dug9xmdwP+N5u9kaL m/UTUPNlnhjpOygpjhQjbmOfALNuzQ/oYXMAlqUCam13MCJf6C8F84zAEGSRJM8Yk2XqhGFtJ CfsHGa6PicKEbyQZakpnctk0utnf+otDHxN+0uumR7teEKgtKzZ9OSusQ1ShkdV2mxsQQISA5 JbZUxBKk1o9CTORTNMEJRQIFEDeQEECOELhGg8ycO7JaNjQT0INE0GLiPVY4E9FSR2hTtPEvO xUwC4vy0LRegb2bqBmzA0NY+qF80RGx8O1Bw53blm0DIa9jYk7pxHQgTY4BoqlBnVi8FdJleb LE8zjHKV/NxNorMBrw/KS2n29x6EKYBErtweGUJv6rcZOv19L7udG12YjcbEY3usOMTtwHpvd as7w0fgTrqN5h1a0rBfBZU7u9msGu3OUNJsLQcsXaYhHbk1cQ0yG++pENMSJt+lej3QuUWky9 Fz79fkOIX7bcTTpz+vVl5EhDcg0MEmfXnzuP0eJmffBkZUiDaIFv6Xu9qUMkiMRSbMpAzNreS LfkAJfBhKQ2kUDiAasNvXIubPQ2QYxZbLhPrXOlefzAkH9TbA3SedWv0LWRISjyqoMCDRvtf3 uyl6L2qIZq3BpydW27tny67AIheaoZu5TuJ+4LfxOa93RLrLEOdcH6Z8gJ2+W4l6GsPqiGnrN 8nLQk23EQcM9OwJPscO4IE1EyZ3NQAPbL+EQ9AI+0I7IQd7qUGR3qHrfCQWMmQKamNBmygKcQ jWvalZE1kILz505iwnd4+jSfSDLo++n0scC+jSSYZNOrp4= From: mails@thomasbley.de (Thomas Bley) ------=_Part_865239_1169202253.1745844029107 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =20 > Edmond Dantes hat am 28.04.2025 13:46 CEST geschrie= ben: > =20 > =20 > Hello all. > =20 > > Yes. And even if it can be made faster (as it looks like Niels is doin= g, which is great), it will never be as fast as an empty constructor and a = return. That's the level I'm proposing. > =20 > If the backtrace is generated only when needed, rather than at the moment= the exception is created, there will be no difference or almost no differe= nce (if a stack unwinding algorithm is used). =20 > =20 > The total number of CPU/memory operations will be approximately the same.= The only difference is that deferred backtrace generation will require mor= e complex frame return code, which may introduce pitfalls. > However, if a backtrace is needed by itself, such overhead is unavoidable= regardless of whether exceptions are used or not. =20 > =20 > > I somewhat glossed over this point, but let me expand on it here. >=20 > So the exception hierarchy in PHP is far from ideal. Understood. The hier= archy can be improved to make it more logical and consistent. And as I unde= rstand it, changing the exceptions themselves is not required for that. =20 > =20 > > Moreover, all exceptions currently track: >=20 > Yes. And the main problem among them is the trace property. Neither file = nor line cause significant overhead, because file is a reference to a strin= g constant, and line is an integer. > =20 > > This is incorrect, as making the current exception system checked would= be a ginormous BC break.=20 > > And having some throwables be checked and some not, but using the same = syntax and class hierarchy... well, that's the reason everyone detests Java= 's exceptions. Let's not do that. >=20 > While introducing a new entity, such as a "New Error Stream" with defined= contract rules, is theoretically possible, > it would not fundamentally change the current situation. >=20 > In practice, this approach would introduce a second category of exception= s, requiring developers to manage: >=20 > * the primary execution flow, >=20 > * the standard exception flow, >=20 > * a "special exception flow" that must be converted back into the standar= d one when necessary. >=20 > This added complexity may outweigh the potential benefits, especially giv= en that the primary value would be limited to preserving backward compatibi= lity.=20 >=20 > It is worth carefully considering whether such a change justifies the add= itional mental and technical overhead. >=20 > On the other side of the scale: >=20 > =20 >=20 > * replacing @throws with a special syntax (or perhaps simply introducing = a new attribute?), >=20 > * defining the behavior in case of contract violation while preserving ba= ckward compatibility. >=20 > For example, if an exception contract is violated, an error would not be = thrown; instead, a warning would be issued, which would not break the progr= am's execution flow but would help draw the developer=E2=80=99s attention t= o the issue. > =20 > Later in the letter you explain in more detail that this is not a special= kind of exception, nor a new execution flow, but rather a special type of = result. =20 > =20 > But if this is a special type of result, then it should follow the same r= ules as all PHP types. In other words, this cannot be solved without gener= ics. >=20 > However, the benefit of the new syntax, which could make the code cleaner= , does not depend on generics: =20 > For example: =20 > =20 > ```php=20 > $res =3D someFunction() catch ($err) {throw $err;} // Like Zig? > ``` > =20 > But then the return type must be Throwable. =20 >=20 > The advantage of generics like Result<> is that they do not create a sepa= rate return channel. > Everything operates within a single flow. > However, this approach is not yet possible in PHP. >=20 > Introducing an additional return channel would mean increasing the overal= l complexity. >=20 > Of course, this is a clean and useful syntax for such cases. > Moreover, the catch block could be made mandatory if the function is mark= ed with a contract =E2=80=94 meaning the function cannot be called without = a catch block at all. >=20 > However, it seems to me that we can achieve the same result using throw, = simply by adding new syntax and capabilities. Yes, there may be some backw= ard compatibility issues, but is it really something to be afraid of? >=20 Hello, =20 looking into userland code, I often see usages for file, line, class, funct= ion, etc. without args. So there are a few options: =20 1) Set zend.exception_ignore_args by default to 1. =20 2) Add a new attribute for custom classes: =20 #[\ExceptionSkipTraceArgs] class BreakException extends \Exception implements Exception =20 3) Implement a new LightException (or similar name) with no args in getTrac= e(). =20 Regards Thomas ------=_Part_865239_1169202253.1745844029107 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
 
Edmond Dantes <edmond.ht@gmail.com> hat am 28.04.2025 13:46 CEST = geschrieben:
 
 
Hello all.=20
 
> Yes.  And even if it can be made faster (as it looks like Ni= els is doing, which is great), it will never be as fast as an empty constru= ctor and a return.  That's the level I'm proposing.
 
If the backtrace is generated only when needed, rather than at the mom= ent the exception is created, there will be no difference or almost no diff= erence (if a stack unwinding algorithm is used).  
 
The total number of CPU/memory operations will be approximately the sa= me. The only difference is that deferred backtrace generation will require = more complex frame return code, which may introduce pitfalls.
However, if a backtrace is needed by itself, such overhead is unavoida= ble regardless of whether exceptions are used or not.  
 
> I somewhat glossed over this point, but let me expand on it here.

So the exception hierarchy in PHP is far from ideal. Understood. The h= ierarchy can be improved to make it more logical and consistent. And as I u= nderstand it, changing the exceptions themselves is not required for that.&= nbsp; 
 
> Moreover, all exceptions currently track:

Yes. And the main problem among them is the trace propert= y. Neither file nor line cause significant overhe= ad, because file is a reference to a string constant, and line is an integer.
 
> This is incorrect, as making the current exception system checked= would be a ginormous BC break. =20
> And having some throwables be checked and some not, but using the= same syntax and class hierarchy... well, that's the reason everyone detest= s Java's exceptions.  Let's not do that.

While introducing a new entity, such as a "New Err= or Stream" with defined contract rules, is theoretically possible,
it would not fundamentally change the current situation.

In practice, this approach would introduce a secon= d category of exceptions, requiring developers to manage:

  • the primary execution flow,

  • the standard exception flow,

  • a "special exception flow" that must be converte= d back into the standard one when necessary.

This added complexity may outweigh the potential b= enefits, especially given that the primary value would be limited to preser= ving backward compatibility. 

It is worth carefully considering whether such a c= hange justifies the additional mental and technical overhead.

On the other side of the scale:

 

  • replacing @throws with a special sy= ntax (or perhaps simply introducing a new attribute?),

  • defining the behavior in case of contract violat= ion while preserving backward compatibility.

For example, if an exception contract is violated, an error would not= be thrown; instead, a warning would be issued, which would not break the p= rogram's execution flow but would help draw the developer=E2=80=99s attenti= on to the issue.
 
Later in the letter you explain in more detail that this is no= t a special kind of exception, nor a new execution flow, but rathe= r a special type of result.  
 
But if this is a special type of result, then it should follow the same rules as all PHP types.  In other words, this canno= t be solved without generics.=20

However, the benefit of the new syntax, which could make the code clea= ner, does not depend on generics:  
For example:  
 
```php 
$res =3D someFunction() catch ($err) {throw $err;} // Like Zig?=20
```
 
But then the return type must be Throwable.  

The advantage of generics like Result<>= ; is that they do not create a separate return channel.
Everything operates within a single flow.
However, this approach is not yet possible in PHP.

Introducing an additional return channel would mea= n increasing the overall complexity.

Of course, this is a clean and useful syntax for s= uch cases.
Moreover, the catch block could be made mandatory if the= function is marked with a contract =E2=80=94 meaning the function cannot b= e called without a catch block at all.

However, it seems to me that we can achieve the sa= me result using throw, simply by adding new syntax and capabil= ities.  Yes, there may be some backward compatibility issues, but is i= t really something to be afraid of?

Hello,
 
looking into userland code, I often see usages for file, line, class, fu= nction, etc. without args.
So there are a few options:
 
1) Set zend.exception_ignore_args by default to 1.
 
2) Add a new attribute for custom classes:
 
#[\ExceptionSkipTraceArgs]
class BreakException extends \Exception implements Exception
 
3) Implement a new LightException (or similar name) with no args in getT= race().
 
Regards
Thomas
------=_Part_865239_1169202253.1745844029107--