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

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,
programmers
can choose to treat them identically. However, if we don't use distinct
error
code, that's soething people can't compensate.

-Ekr


>  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.
>
>
>