Error stack

Charles Kendrick charles at isomorphic.com
Fri Jun 8 12:01:41 PDT 2012


On Fri, Jun 8, 2012 at 5:38 AM, Patrick Mueller <pmuellr at gmail.com> wrote:
> Personally, I'm happy with a user-land way of being able to generate
> something like this, in V8:
>
>     https://gist.github.com/312a55532fac0296f2ab

You can actually do this now in userland in Chrome (except the
CoffeeScript aspect).  This link was posted yesterday:

     http://code.google.com/p/v8/wiki/JavaScriptStackTraceApi

.. but I've subsequently commented on the page with some working code
since people were having trouble understanding how to get to the array
of CallSite objects (it's a pretty bizarre API).

> If there's issues dealing with recursion, or whatever, fine, just tell me
> what they are.

You can't get to function arguments for recursive functions (appears
more than once on stack).  I filed this bug on it, perhaps you'd like
to "star" it:

    http://code.google.com/p/v8/issues/detail?id=2169

Note: Erik just mentioned in passing that debugging APIs have security
implications - this is potentially true for local variable access, but
JavaScript VMs already have to handle correct security for access to
function arguments due to the existing  function.arguments API.  So
nothing new there in terms of risk or burden on the browser
implementer.

> I think that getting access to parm values/locals is interesting, but
> veering into the "land of the debugger".

Just to connect the dots, as I said previously, you don't have a
debugger when you are looking at logs for an application you can't
access.  Programmatic access to this information is critical in that
use case, but also extremely valuable just everyday - how many times
have you seen an application get into an error state that you aren't
sure how to reproduce, when you didn't happen to be in the debugger?
If you had robust stack traces you'd have a lot more to go on.

With IE6 we solved dozens of bugs just from stack trace information.
Ah the good old days!  (yes that's sarcasm + irony)

> I'd prefer a clean take on
> "debugging APIs" rather than evolve it from an exception back-trace use
> case.  When do we start talking about that?  I'm looking at you,
> --expose_debug_as (V8 option).

An Array of StackFrame / CallSite objects is pretty much a clean
debugging API and not really something grafted on.  The same concept
appears in most debug APIs, eg Java's:

    http://docs.oracle.com/javase/1.4.2/docs/guide/jpda/jdi/com/sun/jdi/StackFrame.html

> --
> Patrick Mueller
> http://muellerware.org


More information about the es-discuss mailing list