<story><title>You Really Should Log Client-Side Errors</title><url>http://openmymind.net/2012/4/4/You-Really-Should-Log-Client-Side-Error/</url></story><parent_chain><item><author>rakeshpai</author><text>I&apos;m the developer of Errorception (&lt;a href=&quot;http://errorception.com/&quot; rel=&quot;nofollow&quot;&gt;http://errorception.com/&lt;/a&gt;), and wanted to jump in to talk about some of the points raised on the thread here.&lt;p&gt;As chrisacky mentioned, making one HTTP post for every error is very wasteful. It&apos;s much better to buffer up such errors (Errorception does it in memory, since localStorage can be unavailable and/or full), and post them every once in a while.&lt;p&gt;As masklinn pointed out, window.onerror _is_ complete shit, so Errorception does a couple of tricks to make this slightly better. Firstly, on IE, the stack isn&apos;t lost when window.onerror is called, so it&apos;s possible to get the call stack and arguments at each level of the stack. Secondly, it&apos;s very easy to get other kind of details (browser, version, page, etc.), which helps a great deal in aiding debugging.&lt;p&gt;However, masklinn&apos;s suggestion about wrapping code in try/catch blocks is probably not a good idea. This is because some interpreters (I know v8 does this) don&apos;t compile the code in such code-paths. May cause a performance hit.&lt;p&gt;As DavidPP mentioned, depending on the nature of your application, it might be a good idea to not record too much sensitive information. For example, Errorception doesn&apos;t record function arguments if the page is served over SSL.&lt;p&gt;troels is right - this does create a massive flood of errors. There are several ways to deal with this. What we do for example, is hide away errors from most third-parties - Facebook, Twitter, GoogleBot, GoogleAnalytics, etc. The rest of the errors can still be huge in number, so we group similar errors together based on several parameters like browsers, browser versions, possible variation in inline code line-numbers because of dynamic content, etc.&lt;p&gt;Also, as Kartificial pointed out, this is probably something you don&apos;t want to do on your own server. You want to move this out of your infrastructure, and distribute it if possible.&lt;p&gt;There are other concerns - some that come to mind are page load time, ensuring that your error catching code itself doesn&apos;t raise errors (or if it does, it doesn&apos;t affect your app in any way), and that of managing data-growth on the server. These are fun problems, but it&apos;s probably not worth re-inventing the wheel.&lt;p&gt;&amp;#60;/plug&amp;#62;</text></item></parent_chain><comment><author>ef4</author><text>The V8 performance issue with try/catch is widely misunderstood, and it causes people to unnecessarily avoid using it.&lt;p&gt;try/catch can slow down code &lt;i&gt;in the same function as the try/catch statements&lt;/i&gt;. But it doesn&apos;t slow down any other function called from within there. In other words, it only affects the stack frame at which the try/catch statement actually appears.&lt;p&gt;So if you have some top level error trapping function like:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    errorCatcher = function(continuation){
      try {
        continuation();
      catch(err){
        reportErrorToServer(err);
      }
    }
&lt;/code&gt;&lt;/pre&gt;
and you only call it once at every entry point to your code, the impact will be totally undetectable, because there&apos;s only a single function invocation within the unoptimizable area.&lt;p&gt;I encourage people to performance test the difference caused by try/catch like this. You&apos;ll see that it doesn&apos;t hurt at all. It&apos;s only a problem if you actually write a try statement within some tight inner-loop function.</text></comment>
<story><title>You Really Should Log Client-Side Errors</title><url>http://openmymind.net/2012/4/4/You-Really-Should-Log-Client-Side-Error/</url></story><parent_chain><item><author>rakeshpai</author><text>I&apos;m the developer of Errorception (&lt;a href=&quot;http://errorception.com/&quot; rel=&quot;nofollow&quot;&gt;http://errorception.com/&lt;/a&gt;), and wanted to jump in to talk about some of the points raised on the thread here.&lt;p&gt;As chrisacky mentioned, making one HTTP post for every error is very wasteful. It&apos;s much better to buffer up such errors (Errorception does it in memory, since localStorage can be unavailable and/or full), and post them every once in a while.&lt;p&gt;As masklinn pointed out, window.onerror _is_ complete shit, so Errorception does a couple of tricks to make this slightly better. Firstly, on IE, the stack isn&apos;t lost when window.onerror is called, so it&apos;s possible to get the call stack and arguments at each level of the stack. Secondly, it&apos;s very easy to get other kind of details (browser, version, page, etc.), which helps a great deal in aiding debugging.&lt;p&gt;However, masklinn&apos;s suggestion about wrapping code in try/catch blocks is probably not a good idea. This is because some interpreters (I know v8 does this) don&apos;t compile the code in such code-paths. May cause a performance hit.&lt;p&gt;As DavidPP mentioned, depending on the nature of your application, it might be a good idea to not record too much sensitive information. For example, Errorception doesn&apos;t record function arguments if the page is served over SSL.&lt;p&gt;troels is right - this does create a massive flood of errors. There are several ways to deal with this. What we do for example, is hide away errors from most third-parties - Facebook, Twitter, GoogleBot, GoogleAnalytics, etc. The rest of the errors can still be huge in number, so we group similar errors together based on several parameters like browsers, browser versions, possible variation in inline code line-numbers because of dynamic content, etc.&lt;p&gt;Also, as Kartificial pointed out, this is probably something you don&apos;t want to do on your own server. You want to move this out of your infrastructure, and distribute it if possible.&lt;p&gt;There are other concerns - some that come to mind are page load time, ensuring that your error catching code itself doesn&apos;t raise errors (or if it does, it doesn&apos;t affect your app in any way), and that of managing data-growth on the server. These are fun problems, but it&apos;s probably not worth re-inventing the wheel.&lt;p&gt;&amp;#60;/plug&amp;#62;</text></item></parent_chain><comment><author>xd</author><text>&quot;making one HTTP post for every error is very wasteful.&quot;&lt;p&gt;We implemented this where I work many years back, and as long as you are keeping on top of the errors this isn&apos;t a problem.&lt;p&gt;If you are having to buffer your errors before sending them off to be logged because you are noticing a drain on your resources, you&apos;re doing it wrong.</text></comment>