Add a library to track multiple stack traces

[nex3]

Currently, a future chain that's passing along an error keeps track of only a single stack trace: the stack when the error was originally thrown. This is useful in many cases, but doesn't provide a complete picture of the exception and is less useful when using APIs that return Futures. For example:

    Future<Map> readJson(url) {
      return http.read(url).transform(JSON.parse);
    }

If the call to http.read fails, the stack trace will only contain functions within the http library; it won't give any indication that readJson was called (or the function that called readJson, etc).

As far as I can tell the only way to fully expose the cause of an exception in a Future chain is to record the stack trace at each transform()/chain() call (possibly discarding duplicates). It may be possible to avoid doing this unless an exception is being passed along, which would be good.

[munificent]

Issue #8656 has been merged into this issue.

[nex3]

Added Library-Async label.

[a-siva]

Issue #8656 has been merged into this issue.

[sethladd]

Issue #8656 has been merged into this issue.

[a-siva]

Issue #8656 has been merged into this issue.

[sethladd]

Issue #8656 has been merged into this issue.

[lrhn]

You can capture stack traces that happen after the error, but that's not necessarily helpful in fixing the error. It might give more context to the error, so you can track back the "then"-chain from the error handler to the source of the error.

What you actually want is a "stack trace" chain of the calls that created the future that eventually completed with an error. That is not something we want to do in general, since it would require capturing a stack-trace for each "then" call before we know it's necessary.

---

Removed Type-Defect label.
Added Type-Enhancement label.

[sethladd]

Hi Lasse,

Maybe we can do something in checked-mode, which is already slower but more helpful to the developer. Developing with Futures is quite painful, have you and the lib team come up with any prescriptive techniques for dealing with exceptions "deep in the bowels" of code? I'm at a loss for what to tell developers that run into this. Thanks!

[munificent]

I could deal with this behavior being opt in. I don't even care if it's hard to opt in. Just give me some way to get the stack traces back when an async failure occurs.

One option would be to add a programmatic way to opt-in: some API that lets you set a "capture stack traces before async operations" flag.

[floitschG]

This is now possible with Zones. They get called (registerCallback) when the callback is registered, and when it is invoked.

Not planning on adding more to Futures.

---

Added NotPlanned label.

[nex3]

I'm re-opening this and assigning it to me, since I'm working on a library to do this using Zones, as Florian suggested.

---

Set owner to @nex3.
Removed Library-Async label.
Added Library-StackTrace, Started labels.
Unmarked this as being blocked by #4061.
Changed the title to: "Add a library to track multiple stack traces".

[nex3]

pkg/stack_trace now has support for this, in the form of the Chain class.

---

Added Fixed label.