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

On Thu, Oct 2, 2014 at 6:17 AM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:

>  On 10/2/14, 7:35 AM, Eric Rescorla wrote:
>
> On Wed, Oct 1, 2014 at 11:25 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
>
>>
>>  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.
>
>
> What do you mean "requires an exception to be thrown"? Lots of APIs
> require exceptions be thrown, that doesn't mean code can't catch them.
>

Yes, I don't disagree with that.

-Ekr




> What cowwoc says is backed up by the WebIDL spec's native support for
> promises. To quite the promise guide again [1]:
>
> " promise-returning functions should never synchronously throw errors,
> since that would force duplicate error-handling logic on the consumer: once
> in a catch (e) { ... } block, and once in a .catch(e => { ... }) block.
> Even argument validation errors are not OK. Instead, all errors should be
> signaled by returning rejected promises.
>
> For WebIDL-based specs, this is taken care of automatically by the WebIDL
> specification <https://heycam.github.io/webidl/#es-operations>: any
> exceptions thrown by WebIDL operations, or by the WebIDL overload
> resolution algorithm itself, are automatically converted into rejections. "
>
>  .: Jan-Ivar :.
>
> [1] http://w3ctag.github.io/promises-guide/#always-return-promises
>
>