<div id="reply-content">
I am not sure I understand what does last exception now contain that would be of use to us
</div>
<div id="154AF95CD87E437BA2CC97373EF27D09"><div><br></div>-- <br>Mohamed Ashraf<br><div>Sent with <a href="http://www.sparrowmailapp.com/?sig">Sparrow</a></div><div><br></div></div>
<p style="color: #A0A0A8;">On Wednesday, June 12, 2013 at 9:58 AM, Rouslan Placella wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<div id="quoted-message-content"><div><div>On 06/12/2013 07:50 AM, Mohamed Ashraf wrote:</div><blockquote type="cite"><div><div>I was researching about how to catch errors in javascript. I faced a</div><div>problem. due to the way javascript works for a try block to catch an</div><div>error it has to be within the context of execution which means in the</div><div>following code:</div><div><br></div><div>try {</div><div>function f(){</div><div>throw new Error()</div><div>}</div><div>} catch (e) {}</div><div><br></div><div>calling f(); the error will not be caught in the try block.</div><div>essentially what this means is that if we need to catch the errors</div><div>using try and catch blocks we need to wrap the inside of every</div><div>function with a try block. I am not sure how feasible is this idea but</div><div>it I am sure it would reduce code readability.</div><div><br></div><div>The other option is using window.onerror which allows you to hook a</div><div>function that gets executed whenever an uncaught exception occurs.</div><div>This is obviously much simpler and less invasive and has an upside</div><div>that errors in any context anywhere will still be reported to the</div><div>hooked function. But there is a catch. which is that window.onerror</div><div>does not provide a stacktrace because it is executed in a different</div><div>context from the error itself. what it has access to is the line</div><div>number, file name and exception message.</div><div><br></div><div>so my question is which method should I use, the surrounding all</div><div>functions by try blocks or using the window.onerror callback method?</div><div>how important is the stacktrace?</div></div></blockquote><div><br></div><div>Some of my thoughts are:</div><div><br></div><div>* Try/catch has a performance penalty</div><div>* We need to be able to easily turn off the error reporting feature</div><div>* Some/most function names in the stack trace are going to be useless as</div><div>the production js code is minified.</div><div>* The line numbers in the file will not be of much help either, I guess,</div><div>unless we change the way that the files are minified (like forcing line</div><div>breaks every few hundred characters).</div><div>* If we do want the stack traces, given that we use jQuery, we could tap</div><div>into it and whip up our own traces. For example (completely untested code):</div><div><br></div><div>var lastException;</div><div>(function ($) {</div><div> var bind = $.fn.bind;</div><div> $.fn.bind = function () {</div><div> try {</div><div> throw new Error;</div><div> } catch (exception) {</div><div> lastException = exception;</div><div> }</div><div> bind.apply({}, arguments);</div><div> };</div><div>})(jQuery);</div><div><br></div><div>Later, lastException can be accessed from window.onerror. Of course,</div><div>we'd have to tap into quite a few functions.</div><div><br></div><div>To me it sounds like window.onerror is the winner here.</div><div><br></div><div>Bye,</div><div>Rouslan</div><div>------------------------------------------------------------------------------</div><div>This SF.net email is sponsored by Windows:</div><div><br></div><div>Build for Windows Store.</div><div><br></div><div>http://p.sf.net/sfu/windows-dev2dev</div><div>_______________________________________________</div><div>Phpmyadmin-devel mailing list</div><div>Phpmyadmin-devel@lists.sourceforge.net</div><div>https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel</div></div></div>
</blockquote>
<div>
<br>
</div>