search

whatwg / webidl

Web IDL Standard
https://webidl.spec.whatwg.org/
Other
410 stars 164 forks source link

Allowing throwing an exception with a specific message #1374

Open annevk opened 1 year ago

annevk commented 1 year ago

What problem are you trying to solve?

fetch() throws a TypeError and callers distant from the fetch() call are having a hard time. As we cannot extend TypeError, the current best idea is to standardize on the message: https://github.com/whatwg/fetch/issues/526.

If anyone has better ideas I'd very much appreciate them.

What solutions exist today?

None.

How would you solve it?

Allow create and throw to be passed an optional message argument.

Anything else?

This vaguely relates to #1024.

domenic commented 1 year ago

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

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

annevk commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 7 months ago

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.