W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2013

Re: RTCError, DOMError, and... what happened?

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Tue, 15 Oct 2013 14:48:46 -0400
Message-ID: <525D8E0E.1060405@mozilla.com>
To: public-webrtc@w3.org
On 10/10/13 5:35 PM, Travis Leithead wrote:
> (The multitude of *Error objects is ECMAScript is not seen as a great design.)

#define CENTS 2

I would agree with this. In my mind, errors are for people, not 
computers, so a good message field is all I need. - I don't like APIs 
that consider errors as "part of the API" which encourages callers to 
treat them like another return value their code can conditionally vault 
off of. - e.g Prefer if (!DoesFileExists()) { /**/ } to try{ getFile(); 
} catch (e == ERR_DoesntExist) { /**/ }

#undef CENTS

> Just to throw out a note of caution, I believe that Anne now intends to deprecate/remove DOMError altogether, and just use DOMException objects directly. The goal as I infer it, is to unify all exception/error processing in the DOM into the one object for simplicity and uniformity.

I was under the impression that the goal here was to use DOMException 
for exceptions and DOMError for callbacks and such (which we have a few 
of), but I'm only paying half-attention. Last I looked, this didn't seem 
ready, and I saw the same list of errors for both types, so hopefully we 
can take this a step at a time. I don't think this should lead us to 

I thought I heard some talk back at the Boston interim about simplifying 
our errors, but it was just talk, and I agreed with it, so that doesn't 
count as discussion. I can't find any specific discussion on the list.

.: Jan-Ivar :.
Received on Tuesday, 15 October 2013 18:49:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:51 UTC