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
Received on Thursday, 2 October 2014 13:18:30 UTC