On Tue, 29 Jul 2025 at 01:53, Rob Landers <rob@bottled.codes> wrote:
>
>
> 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
>
*› exceptions that don’t need to get a stack trace from the engine and
could be 100% defined by the developer*
FWIW, that totally solves all of my usecases I've ever encountered: `new
Exception('my message', trace: $myTrace)`
Now since we're talking, if \Exception had a setContext(array $context) +
its getter, I'd be completely happy with it.
That is emulated in the "userland" of Laravel internals - and it also goes
along with PSR-3 <https://www.php-fig.org/psr/psr-3/> which defines a
logger interface as
public function info($message, array $context = array());
And logging, to me at least, is in the same neighborhood as throwing
exceptions - a lot of the time you want some attached data.
*› Disagree. Not all traces can be created locally by the engine. 3rd-party
traces are as useful as regular.*
I think OP meant that there's an internal implementation reason for
getTrace() to not be allowed to be overriden.
