Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128256
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 28 Jul 2025 14:24:11 +0200
To: internals@lists.php.net
Message-ID: <7d83b833-6432-4a86-8e11-b4199fa92430@app.fastmail.com>
In-Reply-To: 
 <CANTuiHvOSimVNPpDxVE5KE8AW63HZmC5=kuSy_uRy_nJRgS9+w@mail.gmail.com>
References: 
 <CANTuiHvOSimVNPpDxVE5KE8AW63HZmC5=kuSy_uRy_nJRgS9+w@mail.gmail.com>
Subject: Re: [PHP-DEV] [DISCUSSION] User-land Throwable
Content-Type: multipart/alternative;
 boundary=b60383ce236143b29e986db1fbca2d57
From: rob@bottled.codes ("Rob Landers")

--b60383ce236143b29e986db1fbca2d57
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Mon, Jul 28, 2025, at 11:41, Dmitry Derepko wrote:
> Hello PHP Internals,
>=20
> I would like to propose a discussion regarding two current limitations=
 in PHP's exception handling system that I believe could be addressed to=
 improve flexibility and developer experience.
>=20
> A few years ago I found that a library printed error traces wrong.
> After a little research I found that there was a mix of 3rd party inte=
gration error + raised error around the current bridge implementation (h=
ttp client).
>=20
> There were several PHP applications with microservices architecture wh=
ich I had access to (docker + sources).
>=20
> So having the message and traces I'd like to have an error chain as it=
 can be done chaining several errors through a new Exception(previous: $=
e).
> But PHP does not allow you to manually implement Throwable. Instead yo=
u should extend Exception. But after that you still cannot override the =
getTrace() method because it's final.
>=20
> So my proposal is pretty simple: Remove both restrictions.
>=20
> 1. Allow user classes to implement Throwable interface directly
>=20
> User classes cannot implement the Throwable interface now.
>=20
> ```php
> class MyCustomThrowable implements Throwable {}
>=20
> // Fatal error: Class MyCustomThrowable cannot implement interface Thr=
owable, extend Exception or Error instead
> ```
>=20
>=20
> 2. Make getTrace() non-final or provide alternative customization mech=
anism
>=20
>=20
> Exception traces cannot be overridden now.
>=20
> ```php
> class MyCustomThrowable extends Exception {
>     function getTrace() { return []; }
> }
>=20
> try { throw new MyCustomThrowable(); }
> catch (Exception $e) { var_dump($e->getTrace()); }
>=20
> // Fatal error: Cannot override final method Exception::getTrace()
> ```
>=20
>=20
> There are some points about the feature:
>=20
> - Microservice support: Preserve traces across service boundaries
> - Proxy/decorator patterns: Maintain original error context through wr=
appers
> - Unified error handling: Any object implementing Throwable can be thr=
own consistently
> - Testing improvements: Create mock throwables for unit tests
> - Performance optimization: Avoid deep call stacks in generated traces
>=20
>=20
> What do you think about it? Are there disadvantages or points to have =
the exceptions in the current state?
> --
> Best regards,
> Dmitrii Derepko.
> @xepozz

Wouldn=E2=80=99t a better approach be to allow serializing/deserializing=
 exceptions?

=E2=80=94 Rob
--b60383ce236143b29e986db1fbca2d57
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv>On Mon, Jul 28, 2025, at 11:41, Dmitry Derepko wrote:</div><blockquot=
e type=3D"cite" id=3D"qt" style=3D""><div dir=3D"ltr"><div><div>Hello PH=
P Internals,</div><div><br></div><div>I would like to propose a discussi=
on regarding two current limitations in PHP's exception handling system =
that I believe could be addressed to improve flexibility and developer e=
xperience.</div><div><br></div><div>A few years ago I found that a libra=
ry printed error traces wrong.</div><div>After a little research I found=
 that there was a mix of 3rd party integration error + raised error arou=
nd the current bridge implementation (http client).</div><div><br></div>=
<div>There were several PHP applications with microservices architecture=
 which I had access to (docker + sources).</div><div><br></div><div>So h=
aving the message and traces I'd like to have an error chain as it can b=
e done chaining several errors through a new Exception(previous: $e).</d=
iv><div>But PHP does not allow you to manually implement Throwable. Inst=
ead you should extend Exception. But after that you still cannot overrid=
e the getTrace() method because it's final.</div><div><br></div><div>So =
my proposal is pretty simple: Remove both restrictions.</div><div><br></=
div><div>1. Allow user classes to implement Throwable interface directly=
</div><div><br></div><div>User classes cannot implement the Throwable in=
terface now.</div><div><br></div><div>```php</div><div>class MyCustomThr=
owable implements Throwable {}</div><div><br></div><div>// Fatal error: =
Class MyCustomThrowable cannot implement interface Throwable, extend Exc=
eption or Error instead</div><div>```</div><div><br></div><div><br></div=
><div>2. Make getTrace() non-final or provide alternative customization =
mechanism</div><div><br></div><div><br></div><div>Exception traces canno=
t be overridden now.</div><div><br></div><div>```php</div><div>class MyC=
ustomThrowable extends Exception {</div><div>&nbsp; &nbsp; function getT=
race() { return []; }</div><div>}</div><div><br></div><div>try { throw n=
ew MyCustomThrowable(); }</div><div>catch (Exception $e) { var_dump($e-&=
gt;getTrace()); }</div><div><br></div><div>// Fatal error: Cannot overri=
de final method Exception::getTrace()</div><div>```</div><div><br></div>=
<div><br></div><div>There are some points about the feature:</div><div><=
br></div><div>- Microservice support: Preserve traces across service bou=
ndaries</div><div>- Proxy/decorator patterns: Maintain original error co=
ntext through wrappers</div><div>- Unified error handling: Any object im=
plementing Throwable can be thrown consistently</div><div>- Testing impr=
ovements: Create mock throwables for unit tests</div><div>- Performance =
optimization: Avoid deep call stacks in generated traces</div><div><br><=
/div><div><br></div><div>What do you think about it? Are there disadvant=
ages or points to have the exceptions in the current state?</div></div><=
div><span class=3D"qt-gmail_signature_prefix">--</span></div><div dir=3D=
"ltr" class=3D"qt-gmail_signature"><div dir=3D"ltr"><div style=3D"color:=
rgb(34, 34, 34);">Best regards,</div><div style=3D"color:rgb(34, 34, 34)=
;"><div dir=3D"ltr"><div dir=3D"ltr">Dmitrii Derepko.</div><div><a>@xepo=
zz</a></div></div></div></div></div></div></blockquote><div><br></div><d=
iv>Wouldn=E2=80=99t a better approach be to allow serializing/deserializ=
ing exceptions?</div><div><br></div><div id=3D"sig121229152">=E2=80=94 R=
ob</div></body></html>
--b60383ce236143b29e986db1fbca2d57--