Selector syntax errors should give better messages

[ajpotts]

I had a bit of a mangled selector on one of my pages which 1.2.6 simply skipped over, but completely kills 1.3.

I should add that I'm aware with 1.3 the correct response should be "Syntax error, unrecognized expression". But I got a far more impenetrable error.

Full test case here:  https://www.partyark.co.uk/html/jquery1.3rc2-bug.html

[dmethvin]

The error is "a[3] is undefined". As you pointed out, $('.box(:not:has(:radio:checked))') is not valid syntax. jQuery doesn't try to give a nice error message for arbitrary selector syntax errors. I'll recategorize this as a enhancement request for better error handling.

[WanderingZombie]

I had a lot of problems in IE upgrading from 1.2.6 to 1.3.0 as the following statement did not result in "Syntax error, unrecognized expression: @href^{=http" being shown when the following statement executed.}

$("a[@href^{=http]").not("a[@href}= http://"+location.hostname+"]").each( blah )

Changing

throw "Syntax error, unrecognized expression: " + expr;

to

alert("Syntax error, unrecognized expression: " + expr);

allowed me to see the error and easily fix it by removing the @'s.

But why did I get an uncaught throw error in the first place?

[dmethvin]

@WanderingZombie, something was probably catching and discarding the error via try/catch, but not having the code it's impossible to tell.

[snover]

Current versions of Sizzle don’t throw errors and just return an object with zero elements. Not sure if that is intentional or not.

[dmethvin]

As we move towards using the browser's native querySelectorAll implementations, there won't be a lot we can do to improve error messages in Sizzle. It might be possible to do better error checking via a plugin but I don't think we'd put it in the production code.