Error stack

Charles Kendrick charles at
Mon Jun 11 16:59:24 PDT 2012

On Mon, Jun 11, 2012 at 4:51 PM, Mark S. Miller <erights at> wrote:
> On Tue, Jun 12, 2012 at 7:38 AM, Brendan Eich <brendan at> wrote:
>> I think Charles was arguing that anyone keeping secrets would need "use
>> strict" to protect those secrets anyway, because otherwise
>> arguments.caller.arguments[i] (given non-strict caller and callee) can get
>> them.
> Non-strict functions should not be assumed to be encapsulated, so it
> would be ok if they leaked info in yet more ways. However, a stack
> consists of a mixture of strict and non-strict activations, so I don't
> see how this helps.

It helps because, whether we are talking about a String API or an OO
API, you make available arguments for non-strict functions, whereas
for strict functions you do not.

This doesn't expose any more information than is already exposed by

This means a library using "use strict" and passing a secret to a
non-strict function might have that secret revealed, and this is,
again, already the case today (via function.arguments).

>> This is a good argument for Error.getStack(errObj), indeed.
> Not Error.getStack. Error is generally available, so if the amplifier
> were Error.getStack, it would be generally available too.
> This leaves open the question of where to get things that are not
> generally available. I hope and expect that we can find good answers
> in the module system. The getStack amplifier should be obtained by
> importing a module that is not generally importable. We've already
> encountered the need for such privileged imports...

I'm reading this as saying that stack traces in general should not be
available unless the code is privileged in some way.  This can't be
what you mean, so could you clarify?

More information about the es-discuss mailing list