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

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

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Tue, 15 Oct 2013 17:03:16 -0400
Message-ID: <525DAD94.7070502@bbs.darktech.org>
To: public-webrtc@w3.org
On 15/10/2013 2: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

     I've got  counter-example. Sometimes you need to extract a subset 
of the error message (for security reasons) and forward it on to someone 
else. For example, when I have a database error on the server I need to 
provide clients with enough information to help developers debug the 
problem, but I don't want to expose internal information such as file 
paths or passwords. Users of the API should never have to 
programmatically parse "message" to do the right thing. In such a case, 
the error API should provide methods that return error-specific information.

Received on Tuesday, 15 October 2013 21:03:45 UTC

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