On Mon, Jul 28, 2025, at 11:41, Dmitry Derepko wrote:
> 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
Wouldn’t a better approach be to allow serializing/deserializing exceptions?
— Rob
