Just mentioning that I couldn't use jsFiddle because of the WinJS nature of the problem. Thanks in advance for any time you guys spend on this.

Tom

If you have "break on throw" set for exceptions in JavaScript, it will stop at least twice.

Don't do that. We throw and catch exceptions inside jQuery itself. Only break on uncaught exceptions.

Wow.. well, I write my software so that it won't have unhandled exceptions (catching at the top level at least), so running with only that really handicaps debugging ability.

I guess there are situations you can't detect without exception throw? That sucks.

well, I write my software so that it won't have unhandled exceptions

jQuery doesn't have unhandled exceptions either. You're asking VS to break on throw, which includes handled ones. If the program is expecting to catch an exception and catches it, that's not an error. We need to be able to do that.

If you have a top-level error handler, break on unhandled exceptions only and put a breakpoint inside the top-level catch.

I understand how to debug around this, but it's much easier to debug an exception at the point it's thrown, rather than multiple levels up the call stack, especially when it's something obscure. That is what makes "break on throw" so useful.

Since most developers strive hard not to use exceptions for logic flow, I have not run into this in any other JavaScript library or any of my own code. I only run into it with jQuery.

If that's not a priority for you guys, I'm going to try to get the Visual Studio team to allow us to do file-based decisions on thrown exceptions in the debugger, since that will still allow me a better debugging experience outside of jQuery.

it's much easier to debug an exception at the point it's thrown

Breaking on unhandled exceptions still breaks on the exception.

Since most developers strive hard not to use exceptions for logic flow, I have not run into this in any other JavaScript library or any of my own code.

When we expect a browser to throw an error and it doesn't, that is a browser bug. Do you have another way to detect something like that?

Breaking on unhandled exceptions still breaks on the exception.

If it's unhandled, yes. Nothing in my app is unhandled. We don't let our apps crash. There's always a "gentle" failure.

When we expect a browser to throw an error and it doesn't, that is a browser bug. Do you have another way to detect something like that?

The only thing I can think of is to use browser detection, since you know which browsers are a problem. I don't like that very much either, but at least the debugging experience would be more useful.

Anyway, I get it. I understand why you're doing it and there's no easy/good way around it. It does kinda suck that you have to do that, but such is life.

I'm going to request the Visual Studio feature I mentioned to make my life easier :)

Thanks for the rapid responses, all!

Of course, you could try not to do it when the file is loaded.. that would be much nicer :)

Just add on the jquery.js file a "try .. catch" statement on the lines you're getting the error. For example, I got an error on line 3686:

matches.call( div, "[s!='']:x" );

So I fixed with:

assert(function (div) {
	try {
	     // Check to see if it's possible to do matchesSelector
	     // on a disconnected node (IE 9)
	     support.disconnectedMatch = matches.call( div, "div" );

	     // This should fail with an exception
	     // Gecko does not error, returns false instead
	     matches.call( div, "[s!='']:x" );
	     rbuggyMatches.push( "!=", pseudos );
	} catch (Exception) { }
});

I don't know if this works for your problems, but it works for me!

Greetings.

Replying to [comment:9 Jahertor]:

I don't know if this works for your problems, but it works for me! Greetings.

I rectify, it seems fixed but not, sometimes still throws Exceptions...

@Jahertor Sizzle already uses a try/catch internally in the assert function. Your code isn't actually doing anything different from what Sizzle already does. Worse, now you can't use versions from a CDN.

jQuery is wrong here. Not Visual Studio.

If you check Safari 7, it will stop every damn time on div.querySelectorAll("*,:x"); when using “stop on unhandled exceptions”. So, this is cross-browser issue.

I just want to say thanks to all of you for documenting this so specifically. It really helps the rest of us quite a bit to come here and find out that we aren't the only ones. Yes it would sure help if we could rectify this in VS in some way.

Well either jQuery or VS should do something to rectify this. It's a very frustrating bug/feature to come across while debugging. It also fails the Windows Store certification process.

I also have the same issue, my app had been working great up until yesterday when I encounted this bug. I have no idea why this suddenly happened.

#14749 is a duplicate of this ticket.