Skip to main content

Bug Tracker

Side navigation

#3834 closed enhancement (wontfix)

Opened January 13, 2009 02:42PM UTC

Closed April 01, 2011 02:27AM UTC

Last modified April 01, 2011 02:27AM UTC

Selector syntax errors should give better messages

Reported by: ajpotts Owned by: john
Priority: low Milestone:
Component: selector Version: 1.4.4
Keywords: Cc:
Blocked by: Blocking:
Description

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

Attachments (0)
Change History (9)

Changed January 15, 2009 02:01PM UTC by john comment:1

milestone: 1.31.3.1
need: ReviewTest Case
version: → 1.3

Changed February 08, 2009 06:31PM UTC by dmethvin comment:2

keywords: selector syntax unrecognizedselector syntax errors
need: Test CasePatch
summary: Failure on selector syntax errorSelector syntax errors should give better messages
type: bugenhancement

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.

Changed March 10, 2009 03:54PM UTC by WanderingZombie comment:3

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?

Changed November 19, 2010 02:25AM UTC by dmethvin comment:4

keywords: selector syntax errorsneedsreview
status: newopen

Changed November 20, 2010 03:35AM UTC by dmethvin comment:5

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

Changed November 23, 2010 01:23AM UTC by snover comment:6

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

Changed November 23, 2010 01:24AM UTC by snover comment:7

milestone: 1.3.1
priority: minorlow
version: 1.31.4.4

Changed April 01, 2011 02:27AM UTC by dmethvin comment:8

resolution: → wontfix
status: openclosed

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.

Changed April 01, 2011 02:27AM UTC by dmethvin comment:9

keywords: needsreview