Error stack

Brendan Eich brendan at
Mon Jun 11 12:57:26 PDT 2012

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 

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?


More information about the es-discuss mailing list