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

On 10/2/14, 7:35 AM, Eric Rescorla wrote:
> On Wed, Oct 1, 2014 at 11:25 PM, cowwoc <cowwoc@bbs.darktech.org 
> <mailto: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.

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 automaticallyby 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