This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25896 - Why is EME creating new DOMException subclasses?
Summary: Why is EME creating new DOMException subclasses?
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: David Dorwin
QA Contact: HTML WG Bugzilla archive list
Depends on:
Blocks: 23367
  Show dependency treegraph
Reported: 2014-05-27 19:00 UTC by Boris Zbarsky
Modified: 2014-09-16 00:44 UTC (History)
6 users (show)

See Also:


Description Boris Zbarsky 2014-05-27 19:00:32 UTC
I thought we were trying to avoid creating new types of exception objects in the platform.
Comment 1 Anne 2014-05-27 19:51:02 UTC
Yes we are. Hopefully we can avoid implementing this.
Comment 2 David Dorwin 2014-05-27 22:45:51 UTC
As far as I know, there are no implementations of this yet.

The discussion of this starts in 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.
Comment 3 Anne 2014-05-28 07:43:42 UTC
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.
Comment 4 Jerry Smith 2014-06-16 19:07:01 UTC
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.
Comment 5 Anne 2014-06-17 05:42:53 UTC
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.
Comment 6 Jerry Smith 2014-07-03 21:04:02 UTC
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.
Comment 7 Anne 2014-07-04 05:43:29 UTC
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?
Comment 8 Jerry Smith 2014-07-07 16:56:10 UTC
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.
Comment 9 Anne 2014-07-11 08:37:46 UTC
Yes I understand you want that, but you have not justified it.
Comment 10 Jerry Smith 2014-07-11 19:02:52 UTC
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.
Comment 11 Anne 2014-07-14 07:43:36 UTC
There is no existing approach for proprietary exceptions. Leaking through details of the CDM like that seems bad.
Comment 12 David Dorwin 2014-07-19 01:33:06 UTC 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.
Comment 13 Anne 2014-07-27 11:28:36 UTC
Thanks David, sounds good.
Comment 14 Jerry Smith 2014-09-16 00:44:41 UTC
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).