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

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>

>> 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 Wednesday, 16 October 2013 14:57:07 UTC