StackTraces

From MemberWiki

Stack traces are very useful navigation tools during debugging sessions: they allow the developer to quickly assess what led to an error in an application by inspecting all the code that led to a specific breakpoint.

Unfortunately, the way modern JavaScript applications are developped, using namespaces and adding anonymous functions as expandos of objects does not help debuggers provide useful information on a given method.

Some debuggers such as Firebug or Venkman can infer a name for anonymous functions from the context of where a function is defined but even that is relatively limited and for example gives no information on the owner of the method:

Anonymous functions in Firebug stack trace

Anonymous functions in Venkman stack trace

In Visual Studio, you only get "anonymous functions" on the stack:

Anonymous functions in Visual Studio stack trace

I don’t know about Drosera as it currently crashes on launch on all of our Macs.

So what we do to get usable stack traces in all tools is that we refactor the debug version of our scripts when we build them so that methods are global functions with names that correspond to the fully-qualified name, but with dots replaced with $ characters. Then we assign those functions as members of our classes.

For example, here’s a simple definition of an object, in release mode:

var foo={bar:function(a){return a;}}

and here’s how it might be transformed in debug mode:

function foo$bar(a) {
  return a;
}
var foo = {
  bar: foo$bar
};

Here’s the sort of stack trace you get if you do that:

Named functions in Venkman stack trace

Named functions in Visual Studio stack trace

Of course, you would never, ever call those APIs using the $ names (which won't exist in release anyway), they're just there to make debugging easier.

I had written a blog post a while ago that explained it in the context of ASP.NET Ajax: [1]