Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128248
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 28 Jul 2025 12:41:02 +0300
Message-ID: <CANTuiHvOSimVNPpDxVE5KE8AW63HZmC5=kuSy_uRy_nJRgS9+w@mail.gmail.com>
Subject: [PHP-DEV] [DISCUSSION] User-land Throwable
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ae480c063afa17aa"
From: xepozzd@gmail.com (Dmitry Derepko)

--000000000000ae480c063afa17aa
Content-Type: text/plain; charset="UTF-8"

Hello PHP Internals,

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.

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
integration error + raised error around the current bridge implementation
(http client).

There were several PHP applications with microservices architecture which I
had access to (docker + sources).

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 you
should extend Exception. But after that you still cannot override the
getTrace() method because it's final.

So my proposal is pretty simple: Remove both restrictions.

1. Allow user classes to implement Throwable interface directly

User classes cannot implement the Throwable interface now.

```php
class MyCustomThrowable implements Throwable {}

// Fatal error: Class MyCustomThrowable cannot implement interface
Throwable, extend Exception or Error instead
```


2. Make getTrace() non-final or provide alternative customization mechanism


Exception traces cannot be overridden now.

```php
class MyCustomThrowable extends Exception {
    function getTrace() { return []; }
}

try { throw new MyCustomThrowable(); }
catch (Exception $e) { var_dump($e->getTrace()); }

// Fatal error: Cannot override final method Exception::getTrace()
```


There are some points about the feature:

- Microservice support: Preserve traces across service boundaries
- Proxy/decorator patterns: Maintain original error context through wrappers
- Unified error handling: Any object implementing Throwable can be thrown
consistently
- Testing improvements: Create mock throwables for unit tests
- Performance optimization: Avoid deep call stacks in generated traces


What do you think about it? Are there disadvantages or points to have the
exceptions in the current state?
-- 
Best regards,
Dmitrii Derepko.
@xepozz

--000000000000ae480c063afa17aa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello PHP Internals,<br><br>I would like to propose a=
 discussion regarding two current limitations in PHP&#39;s exception handli=
ng system that I believe could be addressed to improve flexibility and deve=
loper experience.<br><br>A few years ago I found that a library printed err=
or traces wrong.<br>After a little research I found that there was a mix of=
 3rd party integration error + raised error around the current bridge imple=
mentation (http client).<br><br>There were several PHP applications with mi=
croservices architecture which I had access to (docker + sources).<br><br>S=
o having the message and traces I&#39;d like to have an error chain as it c=
an be done chaining several errors through a new Exception(previous: $e).<b=
r>But PHP does not allow you to manually implement Throwable. Instead you s=
hould extend Exception. But after that you still cannot override the getTra=
ce() method because it&#39;s final.<br><br>So my proposal is pretty simple:=
 Remove both restrictions.<br><br>1. Allow user classes to implement Throwa=
ble interface directly<br><br>User classes cannot implement the Throwable i=
nterface now.<br><br>```php<br>class MyCustomThrowable implements Throwable=
 {}<br><br>// Fatal error: Class MyCustomThrowable cannot implement interfa=
ce Throwable, extend Exception or Error instead<br>```<br><br><br>2. Make g=
etTrace() non-final or provide alternative customization mechanism<br><br><=
br>Exception traces cannot be overridden now.<br><br>```php<br>class MyCust=
omThrowable extends Exception {<br>=C2=A0 =C2=A0 function getTrace() { retu=
rn []; }<br>}<br><br>try { throw new MyCustomThrowable(); }<br>catch (Excep=
tion $e) { var_dump($e-&gt;getTrace()); }<br><br>// Fatal error: Cannot ove=
rride final method Exception::getTrace()<br>```<br><br><br>There are some p=
oints about the feature:<br><br>- Microservice support: Preserve traces acr=
oss service boundaries<br>- Proxy/decorator patterns: Maintain original err=
or context through wrappers<br>- Unified error handling: Any object impleme=
nting Throwable can be thrown consistently<br>- Testing improvements: Creat=
e mock throwables for unit tests<br>- Performance optimization: Avoid deep =
call stacks in generated traces<br><br><br>What do you think about it? Are =
there disadvantages or points to have the exceptions in the current state?<=
br></div><span class=3D"gmail_signature_prefix">-- </span><br><div dir=3D"l=
tr" class=3D"gmail_signature" data-smartmail=3D"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>@xepozz</a></div></div></div></div></div></div>

--000000000000ae480c063afa17aa--