W3C home > Mailing lists > Public > public-media-capture@w3.org > October 2014

Re: Our error-handling is broken (Re: Promise slides)

From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 2 Oct 2014 04:35:50 -0700
Message-ID: <CABcZeBMeXKwaJ9YrM2s0RsVOokdfQJJV+LTMJKJYowN5wzh27g@mail.gmail.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
On Wed, Oct 1, 2014 at 11:25 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:

> On 02/10/2014 2:15 AM, Eric Rescorla wrote:
>> Conveniently, we already agreed months ago that in WebRTC and gUM,
>> error callbacks are used for all runtime error reporting and exceptions
>> are used *solely* for programming errors (i.e., the kind of thing that
>> would
>> be a good candidate for compile-time failures and/or asserts in other
>> languages). Thus, this argument about exceptions is largely irrelevant,
>> leaving us with an argument about the relative aesthetic merits of
>> callback chains versus promises.
> Hi Eric,
> A few months ago I thought this strategy made sense. Having used Promises
> for the past year I now believe that all exceptions (including those
> associated with programming errors) should get returned by the
> callbacks/promises.

I would be generally fine with this as well, though note that there are
some cases where JS simply requires an exception to be thrown.


> Exceptions thrown outside the callback/promise won't get caught by
> developers (who are lazy and won't bother catching exceptions in two
> different places). If all exceptions were tunneled over callbacks/promises,
> then unknown exceptions would typically get logged or otherwise presented
> to the user to pass on to the developer.
> Gili
Received on Thursday, 2 October 2014 11:36:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:30 UTC