Current outstanding issues

[ljharb]

Outstanding issues:

• readme needs lots of fleshing out
  • Rewrite "compatibility" section in readme with systematically reverified data
  • I suspect there'll be pushback to putting getStack on System since it doesn't exist yet - we should be prepared for people to try to suggest Error.getStack. I'm fine with that, but I put an explicit note in the readme that it's irrelevant pre-stage-2.
• spec questions
  • I don't like the top-level property name "span" - could we call it something else?
  • Does the top-level stack object need to be frozen? It might be better to leave it open, and just freeze the "calls" array property
  • Add System.getStackString and make Error#stack use that instead
  • legacy getter for non-error objects (issue)
  • legacy setter (issue, pr)
  • I need to update the Error constructor to populate [[ErrorData]] (stage 2 concern)
• There needs to be a working polyfill, likely adapted from https://rawgit.com/tvcutsem/es-lab/master/src/ses/contract.html (stage 2 concern)
• Still might need some API to exclude stack frames from a given function: which needs more discussion on “just that function” or “all funcs in the callstack above it”, ie, blackbox vs filter (handled by different censorship proposal)

[michaelficarra]

@ljharb Regarding elided stack frames, I only care that the function being censored does not appear in the stack. Functions calling it and called by it may still appear, but there should be no indicator that the censored function participated in the call stack.

[erights]

There needs to be a working polyfill, likely adapted from https://rawgit.com/tvcutsem/es-lab/master/src/ses/contract.html (stage 2 concern)

Shim/polyfill started at https://github.com/erights/error-stack-shim

[conartist6]

I haven't been working specifically towards a shim, but I have made utilities for parsing stack frames, mostly currently those from v8. The repo is here https://github.com/stack-tools-js/stack-tools. This is a heck of lot heavier than using regex, but also regex can't compete in terms of how much weird ambiguous stuff it can parse.

[erights]

Ironically, v8 is the one engine on which a shim does not need to parse/scrape the text representation. We use the v8 Error APIs directly.

How applicable is your parser to the stack traces from other engines?

[conartist6]

Huh, I didn't realize that that wasn't just a node thing. And of course the only good API docs are MDN's, which don't record v8 features. I feel a little silly, but my intuition is that the work is not wasted -- after all, this code will facilitate parsing of all the v8 errors already being thrown without any modification to the environment or the code doing the throwing.

As to stack traces from other engines, I plan to support them. One of the great things about using an honest to goodness parser (and one that is built with support for ambiguous grammars) is that I can describe pretty much any syntax. My hope is that I've made the shape of the AST generic enough that I can use the same tree to represent data parsed from any of the native error syntaxes.

[conartist6]

Actually the next syntax I would add would be Spidermonkey's but I the biggest obstacle is figuring out what their syntax actually is. For v8 I worked from an existing parser package with significant usage...

[conartist6]

Spidermonkey doesn't look that weird, but I just saw a Safari trace for the first time today, and it pretty much blows any clever solution I had been considering (for papering over the platform-specific differences) out of the water.