Error stack

Mark S. Miller erights at
Tue Jun 12 05:19:06 PDT 2012

On Tue, Jun 12, 2012 at 10:14 AM, Charles Kendrick
<charles at> wrote:
> On Mon, Jun 11, 2012 at 5:55 PM, Mark S. Miller <erights at> wrote:
>> On Tue, Jun 12, 2012 at 7:59 AM, Charles Kendrick
>> <charles at> wrote:
>>> 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?
>> That is exactly what I mean.
> The only way I can see this working is if there is a way for a given
> piece of code to trap an error and ask some kind of (elevated
> privilege) logging system to provide diagnostic information that a
> (privileged) end user can see.

I'm not sure what you mean by "trap to an error", but the rest of your
description seems close to how SES's console.log, console.warn, etc
work. They are endowed with access to the privileged getStack function
and use it to display stack traces on the console's output. See

We assume that unprivileged code generally has no way to read the
console's output.

>  It also seems like, in addition to
> this, you should be able to get to stack information programmatically
> so long as you stay within your module or modules that have the same
> privilege.

If we're talking about code with some privilege to see some stacks,
why not reify such privilege in a getStack function importable from
some @privileged module? If you don't reify this distinction, then
you're suggesting above that an access be dependent on the module from
which the access is directly made. What if the access is made
indirectly through some intermediary? Does it then fail, even though
all other accesses can be delegated to the same intermediary? If the
access is simply a property access,

    function intermediary(base, name) { return base[name]; }

defined in some other module.

> This doesn't sound like something that could be reasonably
> standardized into ECMAScript in the near future, and, without all
> those pieces in place, it doesn't seem like ECMAScript should just
> disallow the ability to get stack traces.

In this thread, we've already considered APIs other than ".stack".
Given anything else, why is getStack(err) is any worse than
introducing a novel property name?

Regarding near future, any such proposal -- whether ".stack",
getStack, or whatever -- has already missed the boat for ES6. getStack
certainly could be considered in an ES7 timeframe.

> Brendan brought up SES - I know little about it, but for its sake I
> hope this critical use case is taken into account.

Yes. The code I link to above dates from February.

> On Mon, Jun 11, 2012 at 6:17 PM, Brendan Eich <brendan at> wrote:
>> I thought so too, but Charles is arguing both (a) no worse than today (not better than today); (b) useful for people who prefer
>> non-strict code and a more useful stack-tracing API in the core language.
> Just to clarify, I prefer *some* of the ideas behind "use strict" and
> in fact we built a subset of "use strict" into our in-house tools long
> before JSLint existed.
> But if it's going to impose a security boundary between my own methods
> and reduce the utility of stack traces which are sometimes the only
> thing you have to go on.. no thank you.  That seems to me to conflate
> useful error checking and security; there is overlap, but not 100%
> overlap by any means.

How do getStack and @privileged reduce the utility of stack traces?
Regarding access to arguments, depending on how much privilege
@privileged should give (see questions at end of my previous email),
it is conceivable that it should give access to strict arguments as
well. Or that there be an @turbo_privileged that grants this
additional level of access. Until we have some experience using the
module system on both browser and server, these issues are hard to
think about.


More information about the es-discuss mailing list