> It seems to me we've lost the thread (maybe you haven't, but I have -- > apologies for revisiting).
In a nutshell, I'm looking for access to function arguments, the receiver, and ideally even local variable values via *some* runtime diagnostic API. These could be all be exposed in an error.stack String or in a more OO API (say, error.stackFrames as an array of objects with various properties). I think the best solution is to have *both*. In the field right now, error.stack is a String. Adding error.stackFrames this would mean: 1. we avoid breaking code in the field 2. we provide a convenient error.stack for people who don't want to deal with error.stackFrames 3. we avoid people who want to add richer information having to parse an error.stack String 4. we eliminate all the issues we're running into in trying to standardize error.stack; it wouldn't be so important for it to expose more information or have really smart formatting rules like I previously proposed [1]. It would no longer need to be machine parsable. It might even be OK for it's format to remain completely unspecified since it's just a convenience. The confusing bit: Erik objected to making arguments available in error.stack for security reasons, and Erik is correct that "use strict" implies arguments would not be available in that case. However, I see no issue with error.stack or an error.stackFrames API providing function arguments *only when allowed*; it's not a new security issue or a new burden on browser / VM implementers since they must already correctly implement security checks for the equivalent function.arguments API. [1] https://mail.mozilla.org/pipermail/es-discuss/2012-June/023247.html On Mon, Jun 11, 2012 at 12:57 PM, Brendan Eich <bren...@mozilla.org> wrote: > Charles Kendrick wrote: >> >> On Sat, Jun 9, 2012 at 12:26 PM, Brendan Eich<bren...@mozilla.org> wrote: >>> >>> We do not want a >>> non-debugger API that works only some of the time. >> >> >> What we want (IMO) is an API that allows runtime diagnostics to be >> collected. >> >> By necessity, function arguments would be unavailable for some stack >> frames. >> >> This is not a new situation or a flaw in the proposal, it's a >> situation which exists already for the function.arguments API. > > > It seems to me we've lost the thread (maybe you haven't, but I have -- > apologies for revisiting). I replied because of this flow: > > CK: Erik how do you reconcile this with the fact that this information can > already be obtained in most production browsers via stack walking? > > EA: Stack walking is not available in strict functions > > CK: Interesting, but it doesn't speak against programmatic access to the > call stack. > > At this point I'm not sure what you want -- object references to calling > functions? You're right that we could disclose those where "use strict" does > not poison function.arguments and arguments.callee already, but to what end? > Erik's proposal was about standardizing a string-valued .stack property. > > If we can't have a common string-valued .stack property, we could still make > a new one (.stackString or some such; yech) that doesn't include object > references. > > Is there a strong motivation for sometimes exposing (where "use strict" > allows) object references, or would your use-cases be met by some better > string-valued spec? > > /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
