Could we do less (initially) in this proposal?

[mgaudet]

I think we need to talk about stacks in the spec. I am partially motivated by the fact that I forsee shortly having to write spec text for Error.captureStackTrace, and there’s no real place to hang this off at the moment.

However, the spec text as it exists in the repo today is probably too far.

• Ignoring briefly the addition of the System global, the addition of a programatic stack API is probably a proposal in-and-of-itself. I could imagine it as a way to make the stack trace format changes possible, but probably doesn’t need to be here.

• The specification of the format of stack traces is going to be very hard to get implementers to work on: I suspect very strongly it would be challenging and full of breakage across the JS ecosystem to try to make this change; the existence of our existing divergent formats mean that anyone who is parsing stacks has challenges, yes, but unifying on a format means breakage for everyone who has if (firefox()) { parseFirefoxStack(); }

  This puts everyone in a not great situation where ever vendor is incentivized to keep the status quo, and so this proposal ends up nowhere.

• (This is a nit) I do worry a bit that no matter how big we make the letters around “The contents of the stack are implementation defined” we’ll struggle to dissuade people from taking one stack as the “one true stack” even though for many cases there multiple reasonable stack one could provide (e.g. for an an error thrown during an awaited async function: Do you provide the stack as it existed at the async invocation, or do you show the micro-taskqueue as the caller? -- we do the former, but it does require bookeeping and one could reasonably do the latter!)

So then how to proceed? My personal take is that this proposal should simply be “Stacks exist”; provide a minimal amount of (potentially Annex B) text which indicates Errors may have a stack property.

If it’s compatible, I know SES would prefer V8 have an accessor on the Error prototype, so perhaps if we could get that speced. As to the return value of that getter, I think the text should simply read “An implementation defined string representation of the execution context stack”

[ljharb]

I believe that wouldn't meet a lot of the motivating needs: to be able to delete the stack accessor, and then (Compartments-style) provide a shadowed getStackString implementation (that brand-checks and throws, unlike the accessor).

The getStack API is indeed not strictly necessary, but it is a massive convenience, and the thing that virtually everyone who I've spoken to about this proposal is excited about. In other words, developers desperately want to work with structured data, and stacks currently are just an opaque string that people have to commit atrocities in order to introspect.