Jus*_*tin 4 javascript promise
我所指的规范是http://promises-aplus.github.io/promises-spec/.
使用时then(),您可以返回一个承诺,并在您希望时拒绝承诺,或者您可以抛出异常拒绝承诺.
为什么api不是以这种方式设计的,对于then函数来说,它是像原始的promise构造函数一样传递一个解析和拒绝函数？
许多语言中的异常都很繁重(我也假设在javascript中),所以看起来很奇怪他们将它们用作流控制的选择.创建一个全新的promise对象并返回它,只是为了拒绝它,增加了代码膨胀IMO.如果抛出异常(例如语法错误,或者在未定义的对象上调用函数等),调试也会变得更难.
为什么api不是以这样的方式设计的呢？对于then函数,它传递一个像原始promise构造函数一样的解析和拒绝函数？
实际上,该规范中的API在各种实现中成为共识.但是,可能导致这种情况的一些观点是:
then是一种相当实用的方法.它的回调只应该接收一个数据参数,即promise的结果值.resolve/ reject函数传递给回调不适用于多个参数甚至可变参数函数.then通常用作普通映射函数.你只return需要新值,resolve不需要.resolve/的异步时reject,你最好还是应该使用一个诺言 - 那么你就可以返回了.我曾经使用可选resolve/ reject参数实现了一个Promise lib ,但使用它很繁琐 - 而且由于#4我很少需要它们.使用它们容易出错,您可能很容易忘记某些事情(如处理错误或进度事件) - 就像手动构建和返回从promise回调解决的延迟而不是调用的人一样then.
异常很重,所以看起来很奇怪他们将它们用作流量控制的选择.
它们并不是真正用于控制流程(如分支,循环等),而是用于异常处理:拒绝是特殊的.大多数Promise开发人员都希望将它们作为同步(阻塞)代码的替代方案来实现 - 其中IO总是抛出异常,因此他们对此进行了调整.拒绝仍然被解释为异步等价try … catch,尽管它们的monadic性质可以用于更强大的方式和更高级别的应用程序.
创建一个全新的promise对象并返回它,只是为了拒绝它,增加了代码膨胀IMO.
这里没有太大的区别return new RejectedPromise(…),return reject(…)和throw Error(…).
如果抛出异常(例如语法错误,或者在未定义的对象上调用函数等),调试也会变得更难.
大多数Promise开发人员似乎认为这实际上是一个优势 - 即使在异步代码中也会自动捕获(意外)异常,因此可以处理它们而不是炸毁程序(不被注意).请参阅"LOUD"错误中的异常处理,抛出错误,承诺和可接受的承诺模式？.