Allowing throwing an exception with a specific message

[annevk]

Allowing throwing an exception with a specific message

[domenic]

You can add properties to the TypeError. That seems better?

(It's not currently possible in Web IDL, but we'd add that.)

[annevk]

Yeah maybe. @littledan @syg thoughts from a JS perspective?

Having said, I think that eventually standardizing messages would be good too, but if we can avoid them being the sole mechanism to rely on that would be a lot better.

[syg]

You can add properties to the TypeError. That seems better?

Does this mean adding data properties to TypeError instances created by fetch()? I don't really see any issue with that, aside from unlikely compat issues around libraries that might be doing that already if the new property name is something common.

[domenic]

Does this mean adding data properties to TypeError instances created by fetch()?

Yep, that's what I meant.

(Or, I guess, own accessor properties, but own data properties would make more sense.)

[bakkot]

Node uses error.code = "SOME_FIXED_STRING" and it's great. I would love to see that adopted on the web.

I don't see any problems with it from the JS side, though it's unlikely that errors thrown by JS would get such a property in the near future.

Do note that this can make optimizations which are formally (but not practically) unobservable suddenly be observable: right now if there's two adjacent steps which throw a TypeError and no user code runs between them, an engine can do those steps in whichever order is more convenient for it, and with this change would be required to do them in a particular order. But that's only very rarely going to be an issue, I think, and in any case users already depend on the unspecified message strings and so practically many of these things are observable anyway.