- From: cowwoc <cowwoc@bbs.darktech.org>
- Date: Tue, 15 Oct 2013 17:03:16 -0400
- 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.
Gili
Received on Tuesday, 15 October 2013 21:03:45 UTC