Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127196
Precedence: bulk
MIME-Version: 1.0
References: <39597a9c-6854-40c6-a529-32b2b178cb27@app.fastmail.com>
 <CAMW7n8CNTwOtsUbAbH-0Kk1Ck3DZ1fKF=P9GfctwDk9KmCr2XQ@mail.gmail.com> <64f44c6f-a1ef-4a26-9063-d4d90fdf678c@app.fastmail.com>
In-Reply-To: <64f44c6f-a1ef-4a26-9063-d4d90fdf678c@app.fastmail.com>
Date: Sun, 27 Apr 2025 13:24:51 +0200
Message-ID: <CAB-BujawOX8k=o8PLa6evpA4VO4wKhS3sWJg2KZbwROkPTh6YQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Concept: Lightweight error channels
To: Rob Landers <rob@bottled.codes>
Cc: Edmond Dantes <edmond.ht@gmail.com>, Larry Garfield <larry@garfieldtech.com>, 
	php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: andreas@dqxtech.net (Andreas Hennings)

On Sun, 27 Apr 2025 at 10:27, Rob Landers <rob@bottled.codes> wrote:
>
> On Sun, Apr 27, 2025, at 10:16, Edmond Dantes wrote:
>
> Good afternoon, Larry.
>
> Looking at the comparison table, it seems that the two most important dif=
ferences are:
>
> Backtrace consumes a lot of resources.
>
> There is an explicit contract for exceptions thrown by a function.
>
> I didn't fully understand the point about the exception hierarchy, but it=
 seems important too.
>
> It seems to me that the Backtrace issue is a problem of a low level of ab=
straction =E2=80=94 the implementation of exceptions. That's one problem. T=
he lack of an explicit contract is a problem on a completely different leve=
l of abstraction.
>
> The issue with the missing contract could have been solved even for excep=
tions, without creating a new entity.
>
> Regarding Backtrace, the following questions seem fair:
>
> What if I want to know where the situation occurred? Can I just ignore th=
is information?

For the type of failure we are talking about, there is not really the
need for a backtrace.

>
> If yes, why not create an option to disable backtrace generation for exce=
ptions?
>
> Regarding the Result/Error type.
>
> I have experience using this approach in remote services, where exception=
s seem inappropriate.
> It=E2=80=99s probably possible to use it even now without generics, and w=
ithout any special language features.
>
> What if we focus on:
>
> Improving exception handling, making it as lightweight as in Python.
>
> Introducing explicit exception contracts.
>
> Best Regards, Ed.
>
>
> I'm not going to lie, I spent nearly an hour last night attempting to cre=
ate an exception without a stack trace. I was quite surprised at how imposs=
ible it is. The engine really goes out of its way to ensure the trace is se=
t.

One thing you can do is throw the same exception again.
Not really a good solution though.

>
> A simple solution (for this problem) may be creating a new exception type=
 \LightException or something that would allow for never setting a stack tr=
ace. This is pretty heavily on the "pragmatic" side of the solution space, =
but it is also relatively simple.

The main obstacle here is interface Throwable which promises to have a
file, line number and backtrace.
Currently you can only throw objects that implement Throwable.
https://3v4l.org/LHhNm

If we introduce a "LightException", it cannot really extend Exception,
because then it gets all the baggage.

The solution could be a new interface "Catchable" or "Raisable". But
this would be superfluous.
Instead, we could allow to throw any objects, or introduce a new
keyword "raise", that would allow any objects.

On the implementing side, a "raise new NotFound(..)" seems mostly the
same as "throw new NotFound(..)".
On the declaration side, we might want to add " ... throws NotFound"
or "... raises NotFound", to make this part of the contract. So this
would be very similar to checked exceptions as I know them from Java.

On the calling (and handling) side, any alternative we find to "try
... catch (...) ..." might also be useful for regular exceptions.
In fact this would be the big difference to current exceptions and
return values in terms of developer experience, whereas the "no stack
trace overhead" is more an internal thing.

--- Andreas

>
> =E2=80=94 Rob