Should specify the error messages

[tkrotoff]

Example:

const res = new Response('body');
res.text().then(() => res.text()).catch(e => console.log(`"${e.message}"`));

• Chrome 88: "Failed to execute 'text' on 'Response': body stream already read"
• Firefox 84: "Response.text: Body has already been consumed."
• GNOME Web 3.28.6 (WebKit 605.1.15): "Body is disturbed or locked"
• Microsoft Edge 44 (EdgeHTML 18): "Body has already been read"
• node-fetch 3.0.0-beta.9: "body used already for: "
• whatwg-fetch 3.5.0: "Already read"

The standard is not precise enough: "If object is disturbed or locked, then return a promise rejected with a TypeError."

[annevk]

The message field of exceptions is implementation-defined. I can see why we might want to standardize it, but that should go across all exceptions in the platform, not just this one.

[tkrotoff]

all exceptions in the platform

That would be nice, it's a pain when unit testing things: expect(() => fooBar()).toThrow('...')

not just this one

Starting with Fetch would be a good start :-)

[asutherland]

Given the desires use-case of being able to identify a specific type of error and that:

• many errors are localized (ex: Firefox's en-us dom.properties and all other locales)
• In the case of fetch many details about the specific reason for an error cannot be exposed to content due to cross-origin concerns, but could be exposed to devtools or webdriver which operate with superpowers

I think the platform meta issue might better be to:

• Introduce a specific error subtype / minor error code and continue to leave implementations to their own translations across all locales for message.
• Have the subtype be privileged information that only would be exposed by the platform through testing/devtools superpowers like webdriver and the devtools console rendering of errors. (I proposed something like this briefly a long time ago in Testing behavior for non-standard ports. web-platform-tests/wpt#4751).

So for the specific unit testing situation here, the test would:

1. Need to be running in a context where its global was blessed to be able to see the privileged subtypes or use some super-powered wrapper/oracle function that it imports
2. assert on the subtype and ignore the message

[annevk]

@asutherland I was thinking the opposite. We would standardize message as it's a public field and move the locale-dependent messages (which could be enriched with more information as well) to the console.

[asutherland]

Ah, I definitely see the argument for that. I presume that's something to bring up with the W3C TAG?

[annevk]

Yeah, probably. @cynthia already did some work to that end in w3ctag/design-principles#264.