- From: Domenic Denicola via GitHub <sysbot+gh@w3.org>
- Date: Thu, 21 May 2015 18:31:07 +0000
- To: public-media-capture-logs@w3.org
Thanks for explaining. At first I thought these custom errors were just to satisfy the > We *also* have the issue of returning additional information (such as the constraint that was unsatisfiable in the constraint error case), use case, and did not know about the other case. With that in mind, I guess new types is probably the best way to go. The alternative would be to follow the path of DOMException and have a `.name` that does not align with the constructor name, but it is probably better to follow ES here. With that said, I would still urge caution and consolidation where possible. For example: - OverconstrainedError and ConstraintNotSatisfiedError seem like they could be merged. (I at least can't imagine when distinguishing is going to result in different behavior.) - AbortError, NotSupportedError, and NotFoundError could just use DOMException with the appropriate name; - PermissionDeniedError could probably be a DOMException with name SecurityError - SourceUnavailableError could probably be a DOMException with name NotReadableError I might be wrong on specifics here, where you actually do need to e.g. distinguish a SourceUnavailableError from a NotReadableError, but hopefully you can see the general direction I am driving at. You clearly need at least one new type, to support the additional info about the violated constraint. But after that, being conservative would make more sense. -- GitHub Notif of comment by domenic See https://github.com/w3c/mediacapture-main/pull/170#issuecomment-104379569
Received on Thursday, 21 May 2015 18:31:09 UTC