- From: cowwoc <cowwoc@bbs.darktech.org>
- Date: Thu, 11 Jul 2013 22:54:25 -0400
- To: Paul Neave <paul.neave@gmail.com>
- CC: Adam Bergkvist <adam.bergkvist@ericsson.com>, Rich Tibbett <richt@opera.com>, public-media-capture@w3.org
On 11/07/2013 9:33 AM, Paul Neave wrote: > So to follow on from these implementations, I'd like to suggest the > following to be formally added to the spec: > > 1. PERMISSION_DENIED - User explicitly denied device access via the > browser UI > 2. CONSTRAINT_NOT_SATISFIED - Device access is not possible given > overambitious *mandatory* constraints > 3. HARDWARE_UNAVAILABLE - There is a suitable device connected but a > hardware error occurred (such as OS/program/webpage lock) > 4. NO_DEVICES_FOUND - There are no suitable devices connected whatsoever > > These four cover most use cases in my opinion. One remaining point I > agree with is that it would be useful to know whether the user pressed > the "deny" button, or if the browser has device access disabled (by > the user some time previously or otherwise). So perhaps a fifth error code > > 5. PERMISSION_NOT_ALLOWED - Browser denied device access > > or something else simple and similar to PERMISSION_DENIED would be good. > > There was also talk of having NavigatorUserMediaError inherit from > DOMError, so all of these error code should really be in camelCase, > not UPPER_CASE, see > here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22216 > It goes without saying that I second the motion to add these additional error codes. On the topic of moving from error codes to exception, another benefit is that you can declare error sub-types (meaning, the top-level exception could be PermissionDenied and many sub-types for the different reasons that permission could be denied). Gili
Received on Friday, 12 July 2013 02:55:57 UTC