debugging interfaces

Jordan Osete jor at
Wed Aug 19 03:31:07 PDT 2009

Christian Plesner Hansen wrote :
> I think this is a nice approach[1] but would require language surgery.
>  I would prefer an approach that aligns more closely with existing
> implementations.  
Hm, yes. A backwards compatible approach might be better indeed.
I liked the syntax though, but as current implementations treat it as a 
syntax error, it seems it can't be helped...

David-Sarah Hopwood wrote:
> It would be possible to compile both optimized and deoptimized versions
> of each function, and check in the optimized version whether it is in the
> dynamic scope of such a 'try' block. (Actually, there's no need to restrict
> it to 'try' blocks if doing that.) However, that would still add the
> overhead of the check to the entry code for all optimized (and not inlined)
> functions. I think it would be an overspecification to require any such
> feature.
> As Christian says, we might define a common interface for implementations
> that do want to support this, but I don't think it requires changes to
> language syntax. A 'runWithMoreDebugInfo(someFunction)' API would suffice.
Also, on second thought, using syntax for this detailed / not detailed 
choice may not be the most flexible approach.

Before your mail, I thought of using a specific function to use before 
the given try statement instead:

    Error.detailNextTry( true );
    try{ ... }
    catch( e ){ ... }

...But it feels like a hack. Your solution is indeed more elegant and 
Dunno why I got obsessed with this try statement. ^^;

Christian Plesner Hansen wrote :
> 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
> present.
I don't know if there is that much legacy code like that.
Currently, AFAIK every implementation has a different way to get a stack 
trace, and every browser gives different info formated in different ways 
in those strings, so you have to parse it differently anyway... So 
unless we follow exactly what one of those existing browsers do, users 
will have to adapt their code to use it anyways...
I would really prefer the Error.getStackTrace approach, it is as you say 
more flexible, and doesn't alter the error object. And if someone really 
wants the behavior of captureStackTrace, implementing it herself using 
getStackTrace should be straightforward.


Jordan OSETE

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list