capture error stacktrace as sexp?

capture error stacktrace as sexp?

[Felipe Lema]

Hello, there

Is there a way that, given an `(error ...)` when evaluation some elisp code one could capture the whole stacktrace as a sexp?

My intention is to serialize not only the error but the stacktrace of an error that occurs in a separate Emacs process so I can re-raise the error in /current/ process. You can find more info and context of my intents here: https://melpa.org/#/session-async 

Thanks
Felipe

Re: capture error stacktrace as sexp?

[Stefan Monnier]

Felipe Lema [2021-12-16 15:13:01] wrote:

> Hello, there
>
> Is there a way that, given an `(error ...)` when evaluation some elisp code
> one could capture the whole stacktrace as a sexp?
>
> My intention is to serialize not only the error but the stacktrace of an
> error that occurs in a separate Emacs process so I can re-raise the error in
> /current/ process. You can find more info and context of my intents here:
> https://melpa.org/#/session-async 

I don't think you can "re-raise" the error in another session in a way
that preserves the stack trace, since that would mean preserving the
actual whole stack.

But you can get the current stacktrace with `backtrace-frames` so you
can display it in another session.


        Stefan

Re: capture error stacktrace as sexp?

[Felipe Lema]

On Wednesday, 22 December 2021 14.28.53 -03 Stefan Monnier wrote:
> Felipe Lema [2021-12-16 15:13:01] wrote:
> 
> > Hello, there
> >
> > Is there a way that, given an `(error ...)` when evaluation some elisp code
> > one could capture the whole stacktrace as a sexp?
> >
> > My intention is to serialize not only the error but the stacktrace of an
> > error that occurs in a separate Emacs process so I can re-raise the error in
> > /current/ process. You can find more info and context of my intents here:
> > https://melpa.org/#/session-async 
> 
> I don't think you can "re-raise" the error in another session in a way
> that preserves the stack trace, since that would mean preserving the
> actual whole stack.
> 
> But you can get the current stacktrace with `backtrace-frames` so you
> can display it in another session.
> 
> 
>         Stefan
> 
> 
Thanks for the info,  Stefan... I think this list (which includes the symbols and arguments) should be enough information for user.