On Mon, Jul 28, 2025 at 3:44 PM Rokas Šleinius <rave...@gmail.com> wrote:
> > On Mon, 28 Jul 2025 at 15:16, Lynn <kja...@gmail.com> wrote: > >> >> >> On Mon, Jul 28, 2025 at 1:50 PM Rokas Šleinius <rave...@gmail.com> wrote: >> >>> >>> On Mon, 28 Jul 2025 at 13:56, Tim Düsterhus <t...@bastelstu.be> wrote: >>> >>>> Hi >>>> >>>> Am 2025-07-28 11:41, schrieb Dmitry Derepko: >>>> > 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. >>>> >>>> I'm afraid I don't quite understand what actual goal you intend to >>>> solve >>>> with the proposal. The description of your use case is very abstract, >>>> can you provide a real-world example of a use-case you want to enable? >>>> >>>> Best regards >>>> Tim Düsterhus >>>> >>> >>> | real-world example of a use-case you want to enable >>> >>> Say I am implementing a job runner, I do its error handling, and I want >>> to enrich the caught exception with additional helpful data for debugging. >>> In this process I create a custom exception MyJobHandlerException, but the >>> trace of the new exception includes my handler code, which the end user >>> does not care about. I wish to overwrite the trace of the new >>> MyJobHandlerException instance with the trace from the originally caught >>> exception, but I cannot. >>> >>> I was always sure that the reason behind all methods of \Exception being >>> final is Larry-Garfield-blogpost length/depth so I never bothered to ask >>> and made workarounds. >>> >> >> If I understand you correctly; You rethrow the exception, wrapping it in >> a custom exception class, and you'd like to have a final/composed >> stacktrace of all the exceptions? >> >> https://3v4l.org/m7HIQ#vnull >> > > Yeah you guys come up with nice workarounds, I too, use a custom method on > my exception class to get the "actually relevant" trace, but that's not > compatible with the world at large, and previous() or not, you cannot plug > in your own trace (which was processed for user convenience). > > Another example: what if I want to implement a userland job method > `failed()`, where "the job system" would create a synthetic exception - but > I want it to have the trace up to the actual line in "userland" code (where > `failed()` was invoked) - and I don't want my "system" calls in the trace. > > Or another example: how Laravel handles ViewException - at one point the > error handler builds a "fixed" trace where the compiled Blade files are > replaced in the trace with the source `blade.php` files - as that is what > is actually relevant to the user. I'm cloudy on the details of how exactly > does it perform the switch to display the desired trace, but you can > imagine it would be much nicer to have this code within the concern of the > ViewException itself, but it can't be done now. > Thank you for the cases. I'm not alone here with crazy traces 😀 Btw, I also have a "system" method which creates an exception and guess what? The first trace line is placed in that file. -- Best regards, Dmitrii Derepko. @xepozz
