JavaScript Debugging Enhancements

JavaScript Debugging Enhancements

Rate This
  • Comments 15

Visual Studio 11 Beta introduces a first class JavaScript development experience and provides a rich toolset for developing Windows Metro style apps. Debugging is a crucial part of that toolset. In this post I am going to focus on just some of the new scenarios and enhancements we’ve added to JavaScript debugging experience for this release.

First chance exceptions

In previous versions of Visual Studio you could only break on unhandled exceptions when debugging JavaScript code. Now, for a given exception type, there is an option to break on exception whenever it is thrown. This is done by enabling the corresponding checkbox under Thrown column in the Exceptions dialog (accessible through Debug -> Exceptions menu command). The other column, “User-Unhandled”, does not apply to JavaScript debugging and is therefore disabled (it applies only to CLR exceptions and is used during managed debugging with “Just My Code” on).

image

The default settings enable first chance exceptions for certain error types (for example: Object doesn't support this property or method). When the whole JavaScript Runtime Exceptions category is checked under Thrown, debugger will break on all runtime errors even if they are not listed in the dialog.

First chance exceptions is an important tool when debugging Windows Metro style apps with asynchronous code that uses promises. An exception thrown in a function passed to the then method in a promise is normally “swallowed” by the promise and may not be seen by the developer, especially if there is no error handler passed to the promise chain. With first chance exceptions on, this will now be caught by the debugger and you will break at the throwing statement:

image

In the example above the element ID is misspelled so document.getElementById returns null which results in an “Object expected” exception for which first chance is enabled by default. You can disable first chance exceptions for that particular error type right from the exception thrown dialog by unchecking the checkbox that says “Break when this exception type is thrown”. That way debugger won’t break next time when that exception type is thrown. The Debug Output window will still contain the information about all thrown exceptions:

clip_image002

When breaking on an exception, the Locals window shows the thrown exception object as {exception} which you can expand to see its properties. The number property is what defines the exception type in the debugger exception settings.

clip_image002[5]

Debugging web workers

JavaScript Metro style apps and web apps running in IE10 can use web workers for running JavaScript code in the background. Visual Studio 11 Beta has complete debugging support for web workers. When breaking in the Page context or a worker context, other contexts also stop running. The current context where a break event occurred is shown in the Debug Location toolbar. Page context is shown as the Main Thread whereas a worker context shows the URI of its source document in the thread name.

clip_image004

Switching to a different context while in break mode is not possible: other contexts are suspended but their location is undefined. You can break in a different context by stepping or hitting a breakpoint or exception there.

Other enhancements

  • Stepping through code during JavaScript debugging shows a significant performance improvement compared to Visual Studio 2010.
  • Remote JavaScript debugging is now supported (both on x86/amd64 and ARM remote devices): you can launch JavaScript Metro style apps on a remote device or attach to remote processes running JavaScript code.
  • DOM Explorer and JavaScript Console are two new tool windows, similar to those found in Internet Explorer’s F12 Developer Tools, accessible through Debug -> Windows menu. These windows allow you to work with a running app and try out modifications to styles, the DOM, or code against the running app through the console. In addition, you could make use of the JavaScript APIs for console.log, to record specific events to the console, as you debug.
  • The Call Stack window includes more information such as the line and source file information, giving you more context as you debug without the need of frequently switching to other frames.
    clip_image001

Summary

These are some of the enhancements of JavaScript debugging experience we’ve added with Visual Studio 11 Beta as part of vast improvement in tooling support for JavaScript. As always, we want to hear your feedback. Please report issues through the Visual Studio Connect site. You can add new suggestions for further improvements to UserVoice or vote on existing ones.

 

clip_image002[7]Dmitri Leonov – Software Development Engineer in Test, Visual Studio Ultimate team.

Short Bio: Dmitri Leonov joined the Visual Studio team in 2008. He has been working on the Debugger team since then, where he is now focusing on JavaScript debugging experiences.

Leave a Comment
  • Please add 4 and 5 and type the answer here:
  • Post
  • Looks good, even if I still can't fathom the point of investing so much effort in making JavaScript a first-class citizen in VS.

    I'd be interested to see what languages devs are choosing to use for Metro-style apps once Windows 8 is unleashed on the masses - would Microsoft ever consider releasing that sort of information? My assumptions could be completely off-base.

  • Do these benefits carry over to us web developers?

  • I see we still have that nasty UI...

    How about we get something useful like performance improvements for solutions with 100+ C++ projects?

  • Is it still using IE javascript non-ecma engine?

  • @Chris Marisic: Yes, these improvements directly translate into debugging JavaScript code running in IE10. DOM Explorer and JavaScript console work with IE10 but are hidden by default when debugging some of the project types such as ASP.net web applications. Apart from these tool windows, things listed under “other enhancements” apply to earlier versions of IE as well.

  • @Sla the JavaScript engine in IE has made tremendous progress on implementing the ECMA5 specification. You can see the progress over at the Test 262

    http://test262.ecmascript.org/ for any browser. The IE team also has a blog on the topic at: blogs.msdn.com/.../test262-industry-javascript-standards-test-available.aspx

  • Are there any plans to unify the debugging experience between the IE and VS teams?  

  • @Guy The F12 (Developer Tools) Window in IE10 already has many of the same improvements that Visual Studio debugger has including first chance exceptions, debugging web workers as well as improvements in the Locals window (showing prototype chains, scope chains and the global scope). We have no further plans to share at this point but we appreciate your input.

    Thanks,

    Dmitri Leonov

    Visual Studio Debugger SDET

  • So what is the value of catching JavaScript exceptions when everything .js throws exceptions for flow control?  Even jQuery does this.

  • @Shaun: With asynchronous code that uses promises it can be useful to break on an exception that is thrown in your callback but not caught in your code – as shown in the example above. When calling asynchronous WinRT API’s it is also sometimes useful to break on an exception thrown by the API itself that is again not caught in your code. In the RC release we’ve enabled “user-unhandled” exceptions for JavaScript so now by default you only break on exceptions that are caught in “non-user” code (WinRT and WinJS promise wrappers are marked as such).

  • Hi Dmitri!

    I want to create JavaScript project without dependecies to WinRT. Main idea: use JavaScript as tool script language (as VBScript, Python, bash, etc.) and with all great debugging features from your article (without "debuger" keyword, of course).

    Tell me please, how is it possible (may be via manual/hack edit .jsproj)?

    Thank you!

  • Any word on SourceMap support?

  • The announcement of TypeScript makes source maps in IE a front burner issue.  Are source maps on the road map?

  • @John:

    TypeScript plugin for Visual Studio now supports debugging TypeScript using the source map format:

    blogs.msdn.com/.../announcing-typescript-0-8-1-1.aspx

    Thanks,

    Dmitri Leonov

    Visual Studio Debugger

  • numai bine

    tine o tot asa

Page 1 of 1 (15 items)