Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Any plans to support long stack traces / causality chains? #13

Open
landonpoch opened this issue Nov 18, 2015 · 7 comments
Open

Any plans to support long stack traces / causality chains? #13

landonpoch opened this issue Nov 18, 2015 · 7 comments

Comments

@landonpoch
Copy link

A long stack trace could be very useful for debugging purposes. For example see: https://github.com/kriskowal/q#long-stack-traces.

@ashleydavis
Copy link
Contributor

Sounds like a good idea. Although not sure how we'd achieve that in C#. Got any ideas?

@zsoi
Copy link
Contributor

zsoi commented Nov 18, 2015

I like the idea, too - one could record stack traces manually via the StackTrace class, and then pass traces to the next promise. But sounds like a pretty complicated task, and I'd guess that selectively activating/deactivating the feature may be not so easy to accomplish, because it sounds like a lot of overhead processing. Would it be possible to let "debuggable promises" inherit from the default implementation?

@kibiz0r
Copy link

kibiz0r commented Feb 5, 2016

That's a great idea. zone.js is probably a good inspiration, too.

@bendangelo
Copy link

Any update on this? It would be very useful.

@RoryDungan
Copy link
Contributor

We currently don't have any plans to implement this feature ourselves but would be happy to merge it if someone can figure out an implementation that doesn't break any existing code.

@TinyTeaTree
Copy link

TinyTeaTree commented May 8, 2019

What would a long stack trace look like compare to what we got today?

Currently you get different stack traces on code invoked from the resolver if you resolved after the callbacks were set, or if the callbacks where set after the Promise was resolved.

@timcassell
Copy link

FYI I have this working in my ProtoPromise library. The steps are to capture the current stack trace whenever a new Promise is created. Set that trace to the currently running trace before the callback is executed (in a [ThreadStatic] field). When the stack trace is captured, append it to a list of all the previous stack traces (I store it in a CausalityTrace class that handles it cleanly).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants