Error stack strawman

Mark S. Miller erights at
Thu Feb 18 01:04:39 UTC 2016

On Wed, Feb 17, 2016 at 4:19 PM, Gary Guo <nbdd0121 at> wrote:

> The strawman looks very old, so I've created a new one.
> Repo:
> I've collected many information about current implementation from IE,
> Edge, Chrome and Firefox, but missing Safari's. Many thanks if some one can
> collect these info and create a pull request.
> I haven't write anything for API part, as you will see from the "concerns"
> part, there are many edge cases to be considered: cross-realm, native,
> global, eval, new Function, anonymous and tail call. All of these need to
> be resolved before we can trying to design an object representation of
> stack frame.
> Personally I suggest "(global code)" for global, "(eval code)"  for eval,
> "(Function code)" for new Function, "(anonymous function)" for anonymous
> function/lambda. For native call, we can simply replace filename & line &
> column by "(native)". For tail call I suggest add "(tail)" some where. I
> also suggest adding "(other realm)" or something alike to indicate realm
> boundary is crossed.
> For object representation, I hope something like
> ```
> {
>   name: 'string', // (global code), etc for special case, with parenthesis
>   source: 'url', // (native) for native code, with parenthesis
>   line: 'integer',
>   column: 'integer',
>   isTail: 'boolean'
> }
> ```

Unless the object representation is primary, we will need to agree on
comprehensive escaping rules, and corresponding parsing rules, so that
these stack strings can be unambiguously scraped even when file names and
function names contain parens, slashes, angle brackets, at-signs, spaces,
etc. Therefore, we should focus on the object representation first.

Your object representation above looks like a good start. It is similar to
the extended Causeway stack format I mentioned earlier

    stacktrace ::= {calls: [frame*]};
    frame ::= {name: functionName,
               source: source,
               span: [[startLine,startCol?],[endLine,endCol?]?]};
    functionName ::= STRING;
    startLine, startCol, endLine, endCol ::= INTEGER
    source ::= STRING | frame;

with the following differences:

* You added an isTail. This is probably a good thing. I'd like to
understand better what you have in mind.

* Rather than have a single "span" property with a nested array of numbers
as value, you define separate line and column property names. As long as we
represent all that we need unambiguously, I'm indifferent to minor surface
syntax differences.

* Causeway's format has room for both start(line,col) and end(line,col).
The format must include room for this, and I would hope any future standard
would mandate that they be included. Such span information makes a huge
usability improvement in reporting diagnostics.

* The extended Causeway "source" field could be either a string as with
your's, or a nested frame. This is necessary to preserve the information
currently provided on both FF and Chrome of the nested positions in a
single frame, when a call happens at position X in an eval string that was
evaled by an eval call at position Y. (That is what the "extended" means.
Causeway originally only has strings as the value of their "source"

The proposed[1] API is:

System.getStack(err) -> stack-representation
Reflect.stackString(stack-representation) -> stack-string
System.getStackString(err) -> stack-string

where getStackString is just the obvious composition of getStack and

> And null entry indicating crossing realm. BTW, shall we add reference to
> function in the object representation?

What do you mean by "reference to" above?

[1] Hopefully will resolve in
time that none of these need to be rooted in globals.

> Gary Guo
> _______________________________________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list