Consider following upcoming guidance for RTCError

[domenic]

Hi WebRTC community,

I know you've worked hard to forge your own way on constructing RTCError, due to lack of platform support and guidance. The end result seems pretty reasonable to me, and if it's already implemented everywhere, then great. However, I noticed the "at risk" label in the spec, so I wanted to pop in to see if some small changes were possible, and get your feedback.

In particular, we've finally heard from enough parties that they want customizable exception classes on the platform, that I took some weekend time to write up some guidance for such customizable exception classes. The proposed guidance is at whatwg/webidl#1211, which you can see previewed at https://whatpr.org/webidl/1211.html#idl-DOMException-derived-interfaces .

The results don't quite match what you've done in a few ways:

• They suggest a constructor signature of (message, options), not (options, message), in order to match existing exception classes on the platform which are all exception-first.
• They suggest setting your name to "RTCError", instead of "OperationError".
• They suggest ensuring your exception class is serializable, like all other exception classes.

(Additionally, they give an example of how to use a more modern editorial style while constructing your error class, e.g. using constructor steps that operate on "this". But I don't think that's too important.)

Again, I imagine RTCError has been a painful experience for the community, so I don't want to rock the boat. If it's shipping in various places, then it's fine that it's not quite aligned. But I wanted to give you a heads up, and invite any discussion on the proposed guidance for future cases you might be involved in. And if there's a chance to align, that would be a nice bonus.