Backwards compat concerns with RTCError

[jan-ivar]

Since no browsers implement RTCError yet, concerns were raised about backwards
compatibility with implementing it.

RTCError is both a type (with extra attributes), as well as the name of the error.

One idea to mitigate compat concerns would be to specify the error names browsers are using today. E.g.:

await pc.setRemoteDescription({type: "offer", sdp: "foo"}); // OperationError

On the upside it solves compat. On the downside, JS that cares about the attributes would need to check for them.

[aboba]

@jan-ivar Your suggestion will remove some of the obstacles to implementation, so it's probably a good idea.

[henbos]

This removes an obstacle and makes it backwards-compatible. One might argue RTCError is still At risk though, and that the additional fields introduced by it are only useful for debugging if information is provided by the implementation.

Slide added.

[henbos]

FYI it looks like there are other error names than just OperationError, so an RTCError constructor that passes in a name would be needed.

[henbos]

RTCError are per-spec only constructed in these places:

• RTCDtlsTransport.onerror
• RTCDataChannel.onerror
• SLD/SRD
• replaceTrack

Chrome generally seem to throw OperationError. I saw a case of InvalidModificationError at replaceTrack but I think that's safe to change to OperationError actually because it generally passes.