should URLPattern constructor throw SyntaxError or TypeError for bad patterns?

[wanderview]

should URLPattern constructor throw SyntaxError or TypeError for bad patterns?

[wanderview]

I've been giving this some more thought and I'm leaning towards keeping TypeError and not using SyntaxError. Here are my reasons.

1. Using SyntaxError would result in some weird inconsistencies since URLPattern builds on URL in places. Consider that new URL("blarg") would throw a TypeError, but new URLPattern({ baseURL: "blarg" }) would throw a SyntaxError. This seems weird to me.
2. URLPattern is closer to URL than it is to RegExp. The URLPattern constructor and its getters are fairly closely duck typed to URL. URLPattern does provide test() and exec() methods similar to RegExp, but those do not throw SyntaxErrors as far as I know.
3. I've received spec guidance in the past (I think from @annevk) that in general its not worth over specifying the type of exceptions and APIs should just throw TypeError. I believe this guidance is based on the experience with trying to create granular DOM exceptions in the past.
4. Its asserted above that URL using TypeError instead of SyntaxError is a mistake, but I don't see any issues having ever been opened on the URL spec about that. If it is a problem it doesn't seem very significant.

[domenic]

Hmm, fair point. I guess in an ideal world new URL() would also be using SyntaxError. But given that it isn't, we have to decide whether URL pattern strings are more like RegExps (SyntaxError) or more like URLs (TypeError).

My instinct is they're more like URLs, but it might be reasonable to leave this open to get a bit more feedback. (And close it if nobody has any after a week or so.)

[bakkot]

These feel like they're pretty much halfway between URLs and RegExps to me, so either precedent would be reasonable, which means looking at precedent doesn't help much. From first principles, SyntaxError seems like it makes more sense than TypeError to me as a user, when I write a pattern that has incorrect syntax - "SyntaxError" sounds like "you wrote the string wrong", "TypeError" sounds like "I was expecting you to pass an object rather than a string".

(I don't think it'll matter in practice much either way, though, as long as browsers do a decent job explaining what the problem is in the .message.)

[wanderview]

I'm going to go ahead and call this decided for now.

[domenic]

That's not correct; SyntaxError is used for regexp string syntax errors, as well as BigInt string parsing syntax errors and JSON string parsing syntax errors. It's not constrained to JS source code but instead is used for a variety of parsers in the JS spec.

[annevk]

So per Allen using it for JSON was a mistake, the others all seem like JS source code, but I guess some of that is debatable. Web IDL also still recommends against using it within the web platform.

[wanderview]

I'm personally in favor of using TypeError as it matches new URL() behavior when its passed a bad URL. @domenic, is that compelling to you?

[ljharb]

Given that URL "should" be SyntaxError, why perpetuate the "mistake"?

[wanderview]

Not sure it matters much to the outcome here, but path-to-regexp currently throws TypeError. Just another data point.

[annevk]

I'm pretty sure that SyntaxError is meant exclusively for JavaScript source text syntax errors and is not to be used for other types of syntax errors. See https://www.w3.org/Bugs/Public/show_bug.cgi?id=26961.

Or do you mean "SyntaxError" DOMException? The reason I'm not using that is to make APIs less browser-centric.