debugging interfaces

Christian Plesner Hansen christian.plesner.hansen at
Mon Aug 17 22:23:00 PDT 2009

> Now if I understood it correctly, what makes all this information collection
> performance hungry is really about the arguments and variables. Everything
> else, from the current function name and this object, to the file name and
> in-code localization could be obtained with "acceptable" performance".
> (Please correct me if I am wrong. In particular, to which level of detail
> can we get for "in-code localization" without risking serious slowdown ?
> File name ? Function ? Line number ? Instruction boundaries ?)

You can assume WLOG that capturing arguments and variables will be
relatively expensive for any high-performance implementation.  On the
other hand that doesn't mean that we should disallow it, and having a
common interface for implementations that do implement it would be
good.  For instance, I could imagine extending v8 stack capturing to
include the arguments of just the topmost few frames.

In v8 we record the instruction pointer from which you can infer all
other location information.

> Now, by including a second parameter in the catch clause, the engine knows
> that, for this particular try statement, we need particularly precise
> information, even if it may be at the cost of speed. It becomes an opt-in,
> but a finely grained one - not like a global compile switch.
> Of course, whether the second parameter is present or not, one can still use
> Error.captureStackTrace to get whatever information the engine can give him
> without performance penalties.

I think this is a nice approach[1] but would require language surgery.
 I would prefer an approach that aligns more closely with existing

> Although I must admit I was slightly surprised with this syntax at first, I
> am starting to get used to it now, and I think I like it.
> However I don't understand the part about returning a string. As I
> understood it, it returned a StackTrace object, pretty much like an array of
> stack frames.
> Could you please give us more details about what Error.getStackTrace and
> Error.captureStackTrace exactly do ?

Error.captureStackTrace(e) creates a .stack property on e that returns
the stack trace as a string when accessed.  Error.getStackTrace()
returns a StackTrace object that describes the stack and whose
toString yields a formatted stack trace string.

Error.captureStackTrace is a pretty limited and inflexible interface
but consistent with how .stack works in other implementations.  If you
set the .stack property of your error to the StackTrace object
returned by Error.getStackTrace, which was what I had in mind, you get
a more clean and flexible model but code that can already handle stack
traces may not be able to take advantage of it, for instance if it
uses "typeof e.stack == 'string'" to check if a stack trace is

-- Christian

[1]: Indeed we used this approach for the neptune language, as
described in this blog post:

More information about the es-discuss mailing list