Have a way to get the current stack trace without throwing exceptions.

[nex3]

There's currently no way to get the full, current stack trace. This means that there's also no way for an asynchronous method to give an accurate stack trace when it has an error. For example:

  Future<String> getLinks(String url) {
    return fetchPage(url).transform((html) => parseLinks(html));
  }

Now suppose fetchPage detects an error asynchronously and wants to display a stack trace for that error. A useful stack trace would show that it had originally been called by getLinks, but there's no way for it to know that.

[gbracha]

I'm not sure I understand what you're asking for (and I showed the bug to someone else, who isn't sure either). I could guess, but I'd prefer articulate what you want in more detail.

---

Set owner to @gbracha.
Added NeedsInfo label.

[nex3]

I would like to be able to get a stack trace object (of the same type as you get via try/catch) representing the stack at an arbitrary point of execution. Some sort of "currentStackTrace()" method would work, for example.

If there are other suggestions for how to solve the underlying problem of providing useful stack traces for asynchronous errors, of course, they would also be useful. This is the best solution I can think of.

[DartBot]

This comment was originally written by [email protected]

---

I think this is related: the mirror API could/should allow reflecting on the stack. I experimented with this some time ago (see http://ladicek.github.com/2012/04/09/hacking-the-vm-stack-walking.html), posted on the list and Gilad replied with a sketch of the API: https://groups.google.com/a/dartlang.org/forum/#!msg/misc/81wOAMqgS4w/95mIcroo6ocJ (which is now pretty old, but might still be interesting).

[gbracha]

Eventually, StackMirrors will enable this and more. Of course, getting a trace is very costly, and should generally be discouraged. Of course, for debugging purposes this is absolutely fine.

The trace you get when catching an exception is partial by design, to improve performance and discourage abuse.

---

Added this to the Later milestone.
Removed Type-Defect label.
Added Type-Enhancement label.

[gbracha]

Added Accepted label.

[gbracha]

Issue #3974 has been merged into this issue.

---

cc @sigmundch.

[nex3]

Unfortunately asynchronous code doesn't have the luxury of being able to construct stack traces only when an error actually occurs, but hopefully there will be a way of detecting whether the user is in development or production mode and only grabbing the stack traces in the former case.

[nex3]

Issue #3974 has been merged into this issue.

[nex3]

This has been continuously causing us considerable pain when implementing Pub. The lack of reliable stack traces makes it extremely difficult to debug asynchronous code. Can we set a concrete milestone for this?

---

cc @munificent.
Removed Priority-Medium label.
Added Priority-High label.

[gbracha]

This is up to the VM team at this point. I'll let them know.

[nex3]

Marked this as blocking #7037.

[nex3]

Marked this as blocking #7040.

[nex3]

Gilad, is the API outlined in https://groups.google.com/a/dartlang.org/forum/#!msg/misc/81wOAMqgS4w/95mIcroo6ocJ the one that the VM team would implement?

[gbracha]

Nathan:

That is the proposal we have (or some variant of that). It's known to work (The Newspeak debugger uses something similar) and it allows you to do pretty much anything (say, delimited continuations) on a pay as you go basis. So I would hope the answer is yes, but I won't put words in the VM team's mouth.

[dgrove]

Gilad - This was added to the language spec, right? Can this be closed?

---

cc @alan-knight.

[gbracha]

No and No. There is an API proposal, but it isn't implemented, and the issue if far from solved.

[gbracha]

Changing bug title to clarify what was requested

---

Changed the title to: "Reified cross-isolate stack traces".

[alan-knight]

I'm interested in the much narrower issue that within a single isolate the stack trace you get if you catch an error doesn't print above the catch. So, e.g.
main() {
  foo(50);
}

foo(n) {
  if (n == 0) 3.frobnicate();

  if (n == 3) {
    try {
      return foo(n-1);
    } on Error catch (e, s) {
      print(s);
      return;
    }
  }

  foo(n-1);
}

produces a stack trace with 5 entries rather than 50-some. That seems like a much simpler problem, so I'm not sure if that's part of this bug or should be tracked separately.

[nex3]

That's certainly part of this issue; it's the original motivating case for me reporting it.

[kevmoo]

Never say never - 027b8dc