Re: [DISCUSSION] User-land Throwable

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