Consider aligning WebTransportError with upcoming guidance

[domenic]

In whatwg/webidl#1211, we're attempting to give guidance on how to subclass DOMException, in a similar way to what WebTransportError does. However, our guidance differs from what you've done in the constructor signature, which it suggests would be (message, options) instead of putting message inside options.

We also have some shorthands which can let you avoid creating your own "set up" and "create" operations, which might be nice.

Is it too late to change the constructor signature for WebTransportError? It's a small surface thing, so I don't really want to cause people to do a lot of compat work if it's already shipping and being used extensively. But I thought it'd be worth asking...

[jan-ivar]

@ricea does this SGTY?

[ricea]

It's a breaking change, because

writable.abort(new WebTransportError({streamErrorCode: WT_CODE}));

will create a WebTransportError object with a message of "[object Object]" and a null streamErrorCode. The server will see a different errorCode in the RESET_STREAM message.

On the other hand, I've found no evidence of it being used outside tests.

I have a mild preference for not changing it, because we'd have go through a shipping process for the change and there's no clear migration path, but I will be fine either way.

[jan-ivar]

writable.abort(new WebTransportError({streamErrorCode: WT_CODE}));

will create a WebTransportError object with a message of "[object Object]" and a null streamErrorCode.

Won't this be TypeError, since {streamErrorCode: WT_CODE} isn't a DOMString?

[ricea]

Won't this be TypeError, since {streamErrorCode: WT_CODE} isn't a DOMString?

Almost anything is convertible to DOMString: https://webidl.spec.whatwg.org/#es-DOMString

[jan-ivar]

Meeting:

• @jan-ivar leaning towards fixing it.
• Awkward if different browsers implement this differently.

[jan-ivar]

I suggest we make a decision on this at next meeting.

[jan-ivar]

Meeting:

• No objections