Yes we are. Hopefully we can avoid implementing this.

As far as I know, there are no implementations of this yet.

The discussion of this starts in https://www.w3.org/Bugs/Public/show_bug.cgi?id=23619#c6. In the 10th comment, Microsoft wanted systemCode to remain accessible.

If subclassing is discouraged and the advice in the advice on using DOMException for all errors is still accurate, we should replace MediaKeyError with DOMException. Implementations could choose to report system error codes in the DOMException message.

That sounds acceptable, if it is indeed phrased as a hint towards UAs (with regards to exposing system error codes) and not a requirement as no normative requirements can be made on the contents of .message.

Providing a discrete systemCode for clarity still seems preferable.  A DOMException message could get mingled with errors unrelated to EME.  That could be resolved by adding a clear exception type to the WebIDL, but I've seen some language that appears to discourage doing that.  If so, we could end up using an existing type (or types), like SyntaxError for these messages.

If we do go in this direction, we should preserve the intent of this MediaKeyError text (though modify it to remove the obsolete attribute):  

The systemCode attribute of a MediaKeySession object is a Key System-specific value for the error that occurred. This allows a more granular status to be returned than the more general name. It should be 0 if there is no associated status code or such status codes are not supported by the Key System.

Jerry, if it's key-system specific it seems you should include such details in the message field.

They consideration here is whether you would expect branching to happen based on the exception that is returned. Typically the only thing that happens with exceptions is that they are reported back to the server for debugging.

I've had more discussions on this.  We prefer returning a numeric error code.  It is correct that this is key-system specific.  Is it possible to augment DOMString with an systemCode attribute on the MediaKeySession?  The DOMException message might then identify the exception as Media Key related.

No, it seems it should just go in the exception message. What's the expected usage scenario where it makes sense for this to be exposed as a distinct field only useful for your key system?

The current MediaKeyError provides a numeric systemCode that is key system specific.  This would retain that.  The DOMException message returns string error descriptions.  We prefer a numeric error code.

Yes I understand you want that, but you have not justified it.

The specific concern is that mixing numeric values with text in the DOMException message may make parsing and logging of the numeric value more difficult.  There's potential for the message content to vary by CDM.  The end goal is to be able to accurately parse and log numeric error values.

If there's an existing approach for doing this without a separate numeric error code, please provide a reference to it.

There is no existing approach for proprietary exceptions. Leaking through details of the CDM like that seems bad.

https://dvcs.w3.org/hg/html-media/rev/3368787fe08e removes systemCode as part of a larger removal of definitions that seem likely to change once bug 26372 is resolved. I think we can close this bug and make sure that the solution to bug 26372 does not include subclassing DOMException.

Thanks David, sounds good.

This bug was closed because the underlying issue with extending DOMExceptions was resolved.

The SystemCode discussion from this bug is continued on Bug 26776 - Diagnosing and resolving CDM errors needs a numeric systemCode (deleted with MediaKeyError).