Force Stack Traces with JavaScript

By  on  

I recently inherited a Node.js project and man is that scary.  The code was well written but whenever you inherit a project you instantly inherit the fear of messing things up.  My goal was to fix a fairly routine bug, and finding the issue was fairly easy, but tracing through the code to figure out what called what and what passed what was a nightmare.

So I did the only thing I could do to figure out WTF was going on:

// The magic
console.log(new Error().stack);

/* SAMPLE:

Error
    at Object.module.exports.request (/home/vagrant/src/kumascript/lib/kumascript/caching.js:366:17)
    at attempt (/home/vagrant/src/kumascript/lib/kumascript/loaders.js:180:24)
    at ks_utils.Class.get (/home/vagrant/src/kumascript/lib/kumascript/loaders.js:194:9)
    at /home/vagrant/src/kumascript/lib/kumascript/macros.js:282:24
    at /home/vagrant/src/kumascript/node_modules/async/lib/async.js:118:13
    at Array.forEach (native)
    at _each (/home/vagrant/src/kumascript/node_modules/async/lib/async.js:39:24)
    at Object.async.each (/home/vagrant/src/kumascript/node_modules/async/lib/async.js:117:9)
    at ks_utils.Class.reloadTemplates (/home/vagrant/src/kumascript/lib/kumascript/macros.js:281:19)
    at ks_utils.Class.process (/home/vagrant/src/kumascript/lib/kumascript/macros.js:217:15)
*/

Of course the actual "error" doesn't matter -- the stack trace is exactly what you need to figure out what's calling what up the chain. When available you can also use console.trace() (when available) to achieve roughly the same output.  You can thank me later!

Recent Features

  • By
    Serving Fonts from CDN

    For maximum performance, we all know we must put our assets on CDN (another domain).  Along with those assets are custom web fonts.  Unfortunately custom web fonts via CDN (or any cross-domain font request) don't work in Firefox or Internet Explorer (correctly so, by spec) though...

  • By
    JavaScript Promise API

    While synchronous code is easier to follow and debug, async is generally better for performance and flexibility. Why "hold up the show" when you can trigger numerous requests at once and then handle them when each is ready?  Promises are becoming a big part of the JavaScript world...

Incredible Demos

  • By
    Element Position Swapping Using MooTools 1.2

    We all know that MooTools 1.2 can do some pretty awesome animations. What if we want to quickly make two element swap positions without a lot of fuss? Now you can by implementing a MooTools swap() method. MooTools 1.2 Implementation MooTools 1.2 Usage To call the swap...

  • By
    CSS @supports

    Feature detection via JavaScript is a client side best practice and for all the right reasons, but unfortunately that same functionality hasn't been available within CSS.  What we end up doing is repeating the same properties multiple times with each browser prefix.  Yuck.  Another thing we...

Discussion

  1. Roman

    How about console.trace()?

    • console.trace() doesn’t exist on Chrome on Android.

  2. MaxArt

    How about node-inspector? It lets you use Chrome’s developer tools (sort of) to set breakpoints and inspect the code.
    I’m not debugging any node project without it anymore!

  3. Stuart

    Linked from JavaScript Daily. You can also use node debug whatever.js and put a debugger; statement in the location you want to inspect. Then the bt command will give you the trace.

  4. This is the solution I always use on my apps:

    https://gist.github.com/Venerons/f54b7fbc17f9df4302cf

    You can’t have more info than this. Really.

  5. Loupax

    I used to just call an undefined function in order to make an error appear. Lazy means to the same end I’d say

Wrap your code in <pre class="{language}"></pre> tags, link to a GitHub gist, JSFiddle fiddle, or CodePen pen to embed!