{"id":307,"date":"2009-05-16T19:07:22","date_gmt":"2009-05-17T00:07:22","guid":{"rendered":"http:\/\/www.visophyte.org\/blog\/?p=307"},"modified":"2009-05-16T19:07:22","modified_gmt":"2009-05-17T00:07:22","slug":"better-error-reporting-for-the-mozilla-platform","status":"publish","type":"post","link":"https:\/\/www.visophyte.org\/blog\/2009\/05\/16\/better-error-reporting-for-the-mozilla-platform\/","title":{"rendered":"Better error reporting for the mozilla platform"},"content":{"rendered":"

\"old-and-busted-error-reporting\"<\/a><\/p>\n

If you develop for the mozilla platform, you might be used to error messages like the above.\u00a0 (Or you might wish you got error messages like the above…)\u00a0 An uncaught javascript exception has resulted in a message in the error console as well as some equivalent stdout spew because it’s a debug build.\u00a0 While any error is better than no error, it doesn’t exactly narrow down how we got there.<\/p>\n

Wouldn’t it be nice if we got back-traces for these errors?<\/p>\n

\"new-error-reporting-hotness\"<\/a><\/p>\n

The future is now, people!\u00a0 And it comes in the convenient form of a patch against the 1.9.1 branch, just like you always dreamed!\u00a0 Also, an extension.<\/p>\n

Currently (pre-patch), there are basically 3 ways scripting errors can show up in the platform:<\/p>\n

    \n
  1. nsIScriptError<\/a> instances.\u00a0 These are what show up on the error console.\u00a0 These have information equivalent to a single stack frame.<\/li>\n
  2. nsIException<\/a> instances.\u00a0 These can provide a stack in the form of an nsIStackFrame<\/a> chain (the same thing Components.stack<\/a> gives you).\u00a0 These get converted into nsIScriptError instances when it comes time to report them to the error console.\u00a0 From a stack perspective, only XPConnect produces nsIException instances with stack traces, although you can make your own via Components.Exception<\/a>.\u00a0 A fundamental limitation of these stack traces is that they are only constructed from live JS call stacks, so if a JS exception has unwrapped its way to the top-level you are out of luck.<\/li>\n
  3. JavaScript Error<\/a> instances.\u00a0 These have a private super-rich (it even knows arguments!) call-stack that can only be exposed as a string via the non-standard stack<\/a> attribute.\u00a0 XPConnect understands JS error reports (the ‘flat’ mechanism by which SpiderMonkey reports errors\/exceptions to C++ code), but it has no clue about exceptions and their Error form of existence.\u00a0 The exceptions in their error report guise are converted into nsIScriptError instances.<\/li>\n<\/ol>\n

    What the patch<\/a> (on bug 493414<\/a>) does is:<\/p>\n