Error stack

Charles Kendrick charles at
Mon Jun 11 14:11:09 PDT 2012

> 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

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.


On Mon, Jun 11, 2012 at 12:57 PM, Brendan Eich <brendan at> wrote:
> Charles Kendrick wrote:
>> On Sat, Jun 9, 2012 at 12:26 PM, Brendan Eich<brendan at>  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

More information about the es-discuss mailing list