Error stack strawman

Mark Miller erights at gmail.com
Thu Feb 18 01:40:44 UTC 2016


On Wed, Feb 17, 2016 at 5:36 PM, Gary Guo <nbdd0121 at hotmail.com> wrote:

> * isTail will be set when the frame indicates a frame created by tail call
> instead of normal function call. Caller's frame is already removed so we
> need some indication for that to help debugging.
>

Nice


>
> * For span, I put only one pair of line/column there as it is the common
> implementation, but I agree that a starting position and a ending one is
> useful.
>
> * For source, nested frame could be useful but it is not implemented by
> all implementations, and in fact we need an extra field to distinguish eval
> and new Function.
>

For eval vs Function (vs GeneratorFunction, vs AsyncFunction, etc), doesn't
the name inside the nested frame already deal with that?


>
> * By reference to function, I mean that shall we be able to retrieve the
> function object from the frame?
>

No, absolutely not. The stack rep should provide only info, not access.


>
> * I wonder if putting special cases in (), such as (native) will cause any
> problem. No one will have a file called "(native)" in reality, isn't it?
>

If you do this, they will ;)


>
> Gary Guo
>
> ------------------------------
> Date: Wed, 17 Feb 2016 17:04:39 -0800
> Subject: Re: Error stack strawman
> From: erights at google.com
> To: nbdd0121 at hotmail.com
> CC: es-discuss at mozilla.org
>
>
>
>
> On Wed, Feb 17, 2016 at 4:19 PM, Gary Guo <nbdd0121 at hotmail.com> wrote:
>
> The strawman looks very old, so I've created a new one.
>
> Repo: https://github.com/nbdd0121/es-error-stack
>
> 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"
> property.)
>
> 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
> stackString.
>
>
>
> 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 https://github.com/tc39/ecma262/issues/395 will resolve in
> time that none of these need to be rooted in globals.
>
>
>
>
> Gary Guo
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> --
>     Cheers,
>     --MarkM
>
> _______________________________________________ es-discuss mailing list
> es-discuss at mozilla.org https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
  Cheers,
  --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160217/28443aa0/attachment.html>


More information about the es-discuss mailing list