Error stack

Charles Kendrick charles at
Mon Jun 11 12:00:58 PDT 2012

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.

> Debuggers, in contrast,
> must be able to pierce the veil of "use strict".


> A debugger API is further off from standardization. Mozilla has a new one: ...

This is great but pretty much unrelated - clearly we shouldn't cripple
a runtime diagnostic API because there's a debugger API - these are
two different use cases.

Let's get concrete here - because function.arguments is actually
available but not exposed by error.stack, we have implemented a system
that parses error.stack, using its information to find live function
instances, grabs the arguments and receiver from those and injects
them into a new, enhanced stack trace which we log.

And of course we have to cover the recursive case and show the
arguments as not available..

Because runtime diagnostic information like this is so critical,
you'll see this approach being taken by a bunch of frameworks - don't
you find this distasteful and a clear indication that the standard
should be exposing this information directly?

More information about the es-discuss mailing list