Correct/ Canonical way to preserve stack context when rejecting promises?

[caturria]

Hi folks,

Most importantly I wanted to extend my most sincere gratitude and praise for this wonderful library (and to @bellard for the original)!
I must say I'm having a great time building what will eventually be a scriptable internet radio/ playout system using Quickjs-ng!

I just have one question. When native code returns a promise and later wants to reject it, is there a recommended way of preserving the call stack?

I currently work around this by generating a dummy error before the promising function returns so I can capture its stack info, then if the promise later rejects I can fill in the real error's stack field with what was originally captured.

Is this the cleanest/ most idiomatic way of solving this problem, or is there already a solution to this built in that I've missed?

Thank you.

[bnoordhuis]

When native code returns a promise and later wants to reject it, is there a recommended way of preserving the call stack?

Not at the moment. What you're currently doing is not a bad solution.

We could add a C API that lets you capture the stack trace so you don't have to create and manipulate a dummy Error object, or we could add a (opt-in because of overhead) mode that automatically captures stack traces at await points and stitches them together into a single long stack trace.

[caturria]

Thank you @bnoordhuis!

I was actually quite pleasantly surprised at how modest the overhead from capturing in advance via error object actually turned out to be. As for your two suggestions, I would actually enjoy both for various reasons: having a convenient API for obtaining the concurrent stack trace, and having promises track their origin. Though my current solution works whether script chooses to await or to .then/ .catch which I think is nice.