On Mon, Jul 28, 2025, at 19:54, Kamil Tekiela wrote: > > > On Mon 28 Jul 2025, 20:50 Dmitry Derepko, <xepo...@gmail.com> wrote: >> >> On Mon, Jul 28, 2025 at 3:26 PM Rob Landers <rob@bottled.codes> wrote: >>> >>> Wouldn’t a better approach be to allow serializing/deserializing exceptions? >>> >>> — Rob >> >> It would look like another workaround to my case. Same as deserializing data >> into a class to write into a private property. >> The simpler the better: just allow users to set their own trace. Or not set >> it at all. >> >> -- >> Best regards, >> Dmitrii Derepko. >> @xepozz > > > > I still don't understand what real life use case this solves. Maybe you > already explained it but I didn't get it. IMHO the trace should be set by the > engine and it should not be possible to overwrite the getTrace method. >>
I have a real life use case. I manage an SDK that does RPC. Exceptions from remote services are normalized no matter the language of the RPC. It would be nice to turn these into real exceptions like some of my colleagues do for the SDK other languages. Right now, I simply throw a SyntheticException which encapsulates the original exception and displays the original stack trace as part of the message, but if I could manipulate the stack trace, that would be much more useful to users who end up displaying the php stack trace instead of the one from the remote system. Especially because a lot of frameworks like to truncate messages for some reason that is unknown to me. At least, it would be nice to be able to create synthetic exceptions that don’t need to get a stack trace from the engine and could be 100% defined by the developer — or not, in Larry’s case. — Rob
