{"id":1233,"date":"2012-04-10T12:00:00","date_gmt":"2012-04-10T12:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/visualstudio\/2012\/04\/10\/javascript-debugging-enhancements\/"},"modified":"2022-10-12T10:10:21","modified_gmt":"2022-10-12T17:10:21","slug":"javascript-debugging-enhancements","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/visualstudio\/javascript-debugging-enhancements\/","title":{"rendered":"JavaScript Debugging Enhancements"},"content":{"rendered":"

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\u2019ve added to JavaScript debugging experience for this release.<\/p>\n

First chance exceptions<\/h2>\n

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<\/b> column in the Exceptions dialog (accessible through Debug -> Exceptions menu command). The other column, \u201cUser-Unhandled\u201d, does not apply to JavaScript debugging and is therefore disabled (it applies only to CLR exceptions and is used during managed debugging with \u201cJust My Code\u201d on).\n\"image\"<\/a><\/p>\n

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<\/b> category is checked under Thrown, debugger will break on all runtime errors even if they are not listed in the dialog.<\/p>\n

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<\/b> method in a promise is normally \u201cswallowed\u201d 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:<\/p>\n

\"image\"<\/a><\/p>\n

In the example above the element ID is misspelled so document.getElementById returns null which results in an \u201cObject expected\u201d 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 \u201cBreak when this exception type is thrown\u201d. That way debugger won\u2019t break next time when that exception type is thrown. The Debug Output window will still contain the information about all thrown exceptions:<\/p>\n

\"clip_image002\"<\/a><\/p>\n

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

\"exception<\/a><\/p>\n

Debugging web workers<\/h2>\n

JavaScript Metro style apps and web apps running in IE10 can use web workers<\/a> 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.<\/p>\n

\"clip<\/a><\/p>\n

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.<\/p>\n

Other enhancements<\/h2>\n