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

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

From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 19 Oct 2013 02:02:56 -0700
Message-ID: <CABcZeBNDj3JvOZ_9=R=ZVSPHpnaq+_DhtN64ib7913NbM3AuHQ@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On Wed, Oct 16, 2013 at 7:56 AM, Harald Alvestrand <harald@alvestrand.no>wrote:

> On 10/15/2013 08:48 PM, Jan-Ivar Bruaroey wrote:
>> 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
> <soapbox>
> To my mind, the basic distinction is "if two errors happens, should the
> program do different things?" - if the answer is "yes" for some reasonable
> number of cases, there should be an error code difference; if the answer is
> "no", the diagnostic message is what's important (and that chiefly matters
> to debuggers).
> Message fields generated by programmers are intrinsically incomprehensible
> to ordinary human beings.
> </soapbox>
I concur with this. If we use different error codes for different things,
can choose to treat them identically. However, if we don't use distinct
code, that's soething people can't compensate.


>  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 inaction.
> Well, DOMError isn't an exception, so we can't throw that, no matter how
> much we twist it.
> I interpreted Anne's "suggest throwing out DOMError" as using the
> DOMException data type in both cases.
>> 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.
> What's in the spec is as close to what we discussed in Boston as we've
> been able to get.
Received on Saturday, 19 October 2013 09:04:04 UTC

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