CommonJS Promise 的使用：拒绝与异常
我有一个函数 downloadAsync()，它返回 CommonJS 承诺（使用 问）。它可能会以两种方式失败：
- 文件已经可以下载，在这种情况下我们立即知道。
- 下载过程可能会失败，这种情况我们稍后会知道。
在情况（1）中，因为我在任何异步发生之前就知道，我可以抛出异常。如果是第（2）种情况，我就不得不拒绝这个承诺。
我的问题是，我的 API 应该是统一的，并且始终通过拒绝承诺来发出错误信号吗？或者我应该针对可立即确定的无效状态条件抛出异常？另一个例子，如果用户向我传递了一个无效的参数，那么抛出错误似乎比拒绝承诺更明智。
澄清一下承诺拒绝到底是如何“特殊”的也很好；那里的用法是否与异常使用实践一一对应，或者我们是否也将其用于非异常故障？
I have a function, downloadAsync(), that returns a CommonJS promise (using Q). It can fail in two ways:
- The file can already be downloaded, in which case we know immediately.
- The download process could fail, in which case we know some time later.
In case (1), since I know before anything asynchronous happens, I could throw an exception. In case (2), I'd have to reject the promise.
My question is, should my API be uniform and always signal error by rejecting the promise? Or should I throw exceptions for immediately-determinable invalid state conditions? As another example, if the user passed me an invalid argument, it would seem much more sensible to throw an error than to reject the promise.
Some clarity on how "exceptional" promise rejection really is would be great, as well; does usage there map one-to-one with exception usage practices, or do we use it for non-exceptional failure as well?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您想知道当您的函数（实现 Q）出现可以同步检测到的无效输入时应该做什么，我查看了 Q 的源代码，看看 Q 做了什么。
这是一个例子。
当 Q 收到无效输入时，Q 将使用拒绝对象调用解析器。因此，您可以合理地让您的 API 表现类似，而不是尝试修改底层库的行为。
另外，从任何使用您的 API 的人的角度来看待它。他们想要开发和维护两个还是一个异常处理代码路径？
If you want to know what you should do when your function (which implements Q) should do when presented invalid input that could be detected synchronously, I looked at the source code for Q, to see what Q did.
Here's an example.
When Q is presented with invalid input, Q invokes the resolver with a rejection object. Therefore you could be justified in having your API behave similarly, rather than trying to modify the behavior of the underlying library.
Plus, look at it from a standpoint of anyone who consumes your API. Do they want to develop and maintain two exception handling code paths, or one?
我认为您不需要担心同步情况。 Promise 的工作方式是，当将回调添加到已解决（或拒绝）的 Promise 时，回调应该同步执行。 （嗯，至少在我使用它们的 Dojo 中是这样做的......）
区分拒绝/异常的唯一原因是抛出的承诺对您的应用程序实际上很重要，因为我认为您不能抛出来自承诺回调内部的异常。 （再次强调，这是 Dojo 的承诺，不能 100% 确定你的承诺如何工作......）
I don't think you need to worry about the synchronous case. The way promises work, callbacks should execute synchronously when thay are added to an already resolved(or rejected) promise. (Well, at least they do in Dojo where I use them...)
The only reason to make an reject/exception distinction would be if having a promise thrown was actually important to your application, since I don't think you can throw exception from inside a promise callback. (Again, this is Dojo promises, not 100% sure how yours work...)