On Wed, Feb 17, 2016 at 5:36 PM, Gary Guo <nbdd0...@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: erig...@google.com > To: nbdd0...@hotmail.com > CC: es-discuss@mozilla.org > > > > > On Wed, Feb 17, 2016 at 4:19 PM, Gary Guo <nbdd0...@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@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > > > > -- > Cheers, > --MarkM > > _______________________________________________ es-discuss mailing list > es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
