Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127195
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 27 Apr 2025 10:25:50 +0200
To: "Edmond Dantes" <edmond.ht@gmail.com>,
 "Larry Garfield" <larry@garfieldtech.com>
Cc: "php internals" <internals@lists.php.net>
Message-ID: <64f44c6f-a1ef-4a26-9063-d4d90fdf678c@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8CNTwOtsUbAbH-0Kk1Ck3DZ1fKF=P9GfctwDk9KmCr2XQ@mail.gmail.com>
References: <39597a9c-6854-40c6-a529-32b2b178cb27@app.fastmail.com>
 <CAMW7n8CNTwOtsUbAbH-0Kk1Ck3DZ1fKF=P9GfctwDk9KmCr2XQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Concept: Lightweight error channels
Content-Type: multipart/alternative;
 boundary=d8594c3679414eb3ae3ee0d88eb98e19
From: rob@bottled.codes ("Rob Landers")

--d8594c3679414eb3ae3ee0d88eb98e19
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sun, Apr 27, 2025, at 10:16, Edmond Dantes wrote:
> Good afternoon, Larry.
>=20
> Looking at the comparison table, it seems that the two most important =
differences are:
>=20
>  1. Backtrace consumes a lot of resources.
>=20
>  2. There is an explicit contract for exceptions thrown by a function.
>=20
>  3. I didn't fully understand the point about the exception hierarchy,=
 but it seems important too.
>=20
> It seems to me that the Backtrace issue is a problem of a low level of=
 abstraction =E2=80=94 the implementation of exceptions. That's one prob=
lem. The lack of an explicit contract is a problem on a completely diffe=
rent level of abstraction.
>=20
> The issue with the missing contract could have been solved even for ex=
ceptions, without creating a new entity.
>=20
> Regarding Backtrace, the following questions seem fair:
>=20
>  1. What if I want to know where the situation occurred? Can I just ig=
nore this information?
>=20
>  2. If yes, why not create an option to disable backtrace generation f=
or exceptions?
>=20
> Regarding the Result/Error type.
>=20
>=20
> I have experience using this approach in remote services, where except=
ions seem inappropriate.
> It=E2=80=99s probably possible to use it even now without generics, an=
d without any special language features.
>=20
> What if we focus on:
>=20
>  1. Improving exception handling, making it as lightweight as in Pytho=
n.
>=20
>  2. Introducing explicit exception contracts.
>=20
> Best Regards, Ed.

I'm not going to lie, I spent nearly an hour last night attempting to cr=
eate an exception without a stack trace. I was quite surprised at how *i=
mpossible* it is. The engine really goes out of its way to ensure the tr=
ace is set.

A simple solution (for this problem) may be creating a new exception typ=
e \LightException or something that would allow for never setting a stac=
k trace. This is pretty heavily on the "pragmatic" side of the solution =
space, but it is also relatively simple.

=E2=80=94 Rob
--d8594c3679414eb3ae3ee0d88eb98e19
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Sun, Apr =
27, 2025, at 10:16, Edmond Dantes wrote:</div><blockquote type=3D"cite" =
id=3D"qt" style=3D""><div dir=3D"ltr"><p class=3D"qt-gmail-">Good aftern=
oon, Larry.</p><p class=3D"qt-gmail-">Looking at the comparison table, i=
t seems that the two most important differences are:</p><ol><li class=3D=
"qt-gmail-"><p class=3D"qt-gmail-">Backtrace consumes a lot of resources=
.</p></li><li class=3D"qt-gmail-"><p class=3D"qt-gmail-">There is an exp=
licit contract for exceptions thrown by a function.</p></li><li class=3D=
"qt-gmail-"><p class=3D"qt-gmail-">I didn't fully understand the point a=
bout the exception hierarchy, but it seems important too.</p></li></ol><=
p class=3D"qt-gmail-">It seems to me that the Backtrace issue is a probl=
em of a low level of abstraction =E2=80=94 the implementation of excepti=
ons. That's one problem.=0AThe lack of an explicit contract is a problem=
 on a completely different level of abstraction.</p><p class=3D"qt-gmail=
-">The issue with the missing contract could have been solved even for e=
xceptions, without creating a new entity.</p><p class=3D"qt-gmail-">Rega=
rding Backtrace, the following questions seem fair:</p><ol><li class=3D"=
qt-gmail-"><p class=3D"qt-gmail-">What if I want to know where the situa=
tion occurred? Can I just ignore this information?</p></li><li class=3D"=
qt-gmail-"><p class=3D"qt-gmail-">If yes, why not create an option to di=
sable backtrace generation for exceptions?</p></li></ol><div><p class=3D=
"qt-gmail-">Regarding the Result/Error type.</p><p class=3D"qt-gmail-"><=
/p><div>I have experience using this approach in remote services, where =
exceptions seem inappropriate.</div><div> It=E2=80=99s probably possible=
 to use it even now without generics, and without any special language f=
eatures.</div><p></p><p class=3D"qt-gmail-">What if we focus on:</p><ol>=
<li class=3D"qt-gmail-"><p class=3D"qt-gmail-">Improving exception handl=
ing, making it as lightweight as in Python.</p></li><li class=3D"qt-gmai=
l-"><p class=3D"qt-gmail-">Introducing explicit exception contracts.</p>=
</li></ol><div>Best Regards, Ed.</div></div></div></blockquote><div><br>=
</div><div>I'm not going to lie, I spent nearly an hour last night attem=
pting to create an exception without a stack trace. I was quite surprise=
d at how&nbsp;<b>impossible</b> it is. The engine really goes out of its=
 way to ensure the trace is set.</div><div><br></div><div>A simple solut=
ion (for this problem) may be creating a new exception type \LightExcept=
ion or something that would allow for never setting a stack trace. This =
is pretty heavily on the "pragmatic" side of the solution space, but it =
is also relatively simple.<br></div><div><br></div><div id=3D"sig1212291=
52">=E2=80=94 Rob</div></body></html>
--d8594c3679414eb3ae3ee0d88eb98e19--