[webkit-dev] Blog post draft: dealing with exceptions using Web Inspector

Yury Semikhatsky yurys at chromium.org
Wed Apr 13 02:02:47 PDT 2011


Including the draft content inline for those who don't have post
permissions.

Thanks,
Yury



Web Inspector: Understanding Stack
Traces<http://www.webkit.org/blog/?p=1544>Posted
by *Yury Semikhatsky* on Wednesday, April 13th, 2011 at 1:44 am

Finding errors in JavaScript code both during application development and
when it’s already released is an important part of web development. We’ve
recently added a mechanism for handling uncaught JavaScript exceptions and
made some improvements in the tools that allow you to work with stack
traces. Now it’s a good time to summarize the ways one can deal with
exceptions and stack traces in WebKit.
Tracking exceptions

When something goes wrong, you open the Web Inspector console (Ctrl+Shift+J
/ Cmd+Option+J) and find a number of JavaScript error messages there. Each
message has a link to the file name with the line number you can navigate
to.

However, there might be several execution paths that lead to the error and
it’s not always obvious which one of them has happened. Since recently, once
Web Inspector window is opened, exceptions in the console are accompanied
with the complete JavaScript call stacks. You can expand these console
messages to see the stack frames and navigate to the corresponding locations
in the code:

You may also want to pause JavaScript execution next time exception is
thrown and inspect its call stack, scope variables and state of your app. A
tri-state stop button  at the bottom of the Scripts panel enables you to
switch between different exception handling modes: you can choose to either
pause on all exception or only on the uncaught ones or you can ignore
exceptions altogether.

Printing stack traces

Printing log messages to the Web Inspector console is also very helpful in
understanding how your application behaves. Now you can make the log entries
even more informative by including associated stack traces. There are
several ways of doing that.

   - You can instrument your code with console.trace() calls that would
   print current JavaScript call stacks:

   - There is also a way to place assertion in your JavaScript code. Just
   call console.assert() with the error condition as the first parameter.
   Whenever this expression evaluates to false you will see a corresponding
   console record:


Handling exceptions at runtime using window.onerror

Recently we’ve added support for setting a handler function to
window.onerror. Whenever a JavaScript exception is thrown in the window
context and is not caught by any try/catch block, the function will be
invoked with the exception’s message, the URL of the file where the
exception was thrown and the line number in that file passed as three
arguments in that order. You may find it convenient to set an error handler
that would collect information about uncaught exceptions and report it back
to your server.

Note that for more information on the recent features of the Web Inspector,
you can visit the Chrome
DevTools<http://code.google.com/chrome/devtools/docs/overview.html>
documentation
page.

You can follow any responses to this entry through the RSS
2.0<http://www.webkit.org/blog/?p=1544/feed/> feed.
Both comments and pings are currently closed. Edit this
entry.<http://www.webkit.org/blog/wp-admin/post.php?action=edit&post=1544>

Comments are closed.

On Wed, Apr 13, 2011 at 10:35 AM, Yury Semikhatsky <yurys at chromium.org>wrote:

> Hello everyone,
>
> I've prepared a blog post draft(
> http://www.webkit.org/blog/?p=1544&preview=true) that gives an overview
> of various ways of dealing with JavaScript stack traces and exceptions
> using Web Inspector. Your comments
> and suggestions are welcome.
>
> Thanks,
> Yury
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110413/6c3eb45f/attachment.html>


More information about the webkit-dev mailing list