“大声"错误的可接受承诺模式? [英] acceptable promise pattern for 'LOUD' errors?

问题描述

我正在使用分布在 Ember.js 中的 RSVP 库，我正在尝试找出在承诺中报告致命错误的正确模式——特别是我想通知一些几乎可以肯定是编程结果的事情由于 api 滥用而导致的错误，我想以一种大声的方式来做.我是 Promise 和 javascript 的新手，希望这个问题有意义

I'm using the RSVP library distributed inside Ember.js and I'm trying to figure out the correct pattern for reporting fatal errors inside a promise -- particularly I want to inform of something that's almost certainly the result of a programming error due to api misuse and I want to do it in a LOUD way. I'm new to promises and javascript in general, hopefully this question makes sense

这是一个简单的例子(在咖啡脚本中):

Here's a simple example (in coffeescript):

doAsync = (arg, callback) ->
  throw new Error('you gave me a way bad arg, I fail for you!')

promiseReturningApi = (data) ->
  return new Ember.RSVP.Promise (resolve, reject) ->
    callback = (err, resp) ->
      if err then reject(err)
      else resolve(resp)
    doAsync(data, callback)

现在假设我已经确定了一个错误，在 doAsync 中发生的错误无法恢复——我想确保即使调用者忽略附加错误处理程序，也会报告此错误，因为它几乎可以肯定只是导致调用者调用api函数的方式不正确

Now lets say I've identified an error that there's no possible way to recover from which occurred inside doAsync -- I want to make sure this error gets reported even if the caller neglected to attach an error handler because it almost certainly only resulted because the caller invoked the api function in an incorrect way

我想到了在拒绝处理程序中使用 setTimeout 的想法，以确保从 某处 引发错误，即使调用者没有将错误处理程序附加到承诺中

I came across the idea of using setTimeout within a rejection handler to ensure the error gets raised from somewhere even if the caller doesn't attach an error handler to the promise

failLoud = (err) ->
  if err.isProgrammerError
    setTimeout () ->
      throw err
  throw err

promiseReturningApi = (data) ->
  promise = new Ember.RSVP.Promise (resolve, reject) ->
    callback = (err, resp) ->
      if(err) then reject(err)
      else resolve(resp)
    doAsync(data, callback)
  return promise.then(null, failLoud)

在从我的 promiseReturningApi 返回之前将这样的默认错误处理程序附加到承诺是否被认为是一种合理的做法?这将允许我在调用者做了一些不可能工作的事情时强制进行堆栈跟踪——即使堆栈跟踪有点奇怪，它可以让事情更容易开始......

Is it considered a reasonable practice to attach such a default error handler to a promise before returning it from my promiseReturningApi? This would allow me to force a stacktrace when the caller does something that can't possibly work -- even though the stacktrace would be a little odd it could make things a bit easier to get started with ...

即使我将示例承诺返回函数称为api"调用——我应该补充一点，我不是在编写框架代码——这一切都在应用程序中.如果 doAsync 是一个真实世界的函数，那么在我的真实世界版本中，它很可能来自具有新用户 API 的外部方——所以我很可能会在使用它时滥用它我开始了解它......意思是我可能想要制作这样的图案

Even though I called the example promise returning function an 'api' call -- I should add that I'm not writing framework code -- this is rather all within an application. If doAsync were a real-world function, then in my versio of the real-world its pretty likely to be coming from an external party with a new-to-me api -- so it seems pretty likely that I'll misuse it while I'm getting to know it... Meaning I might want to make the pattern something like this

failLoud = (err) ->
  if err?.isProgrammerError
    setTimeout () ->
      throw err
  throw err

promiseReturningApi = (data) ->
  promise = new Ember.RSVP.Promise (resolve, reject) ->
    callback = (err, resp) ->
      if(err) reject(err)
      resolve(resp)
    try
      doAsync(data, callback)
    catch err
      err.isProgrammerError = true
      throw err
   return promise.then(null, failLoud)

我认为这样做是在我的异步函数调用本身引发异常的任何时候强制从 某处 抛出异常——这样的异常几乎肯定会在参数期间引发异步调用的验证阶段，这通常是我的应用程序代码传入没有任何意义的东西的结果——我想尽快找出答案.在这种情况下，这似乎是一种合理的模式，可以帮助调试应用程序代码中使用的承诺?

I think what this is doing is forcing an exception to be thrown from somewhere any time that my asynchronous function call invocation itself raises an exception -- such an exception would almost certainly be raised during the argument validation phase of the async call which is most commonly going to be the result of my application code passing in something which doesn't make any sense -- and I want to find out about that as soon as I can. Does this seem like a reasonable pattern to follow to aid in debugging promises used in application code in this context?

推荐答案

新答案 --

在这个与 ember 核心开发人员的视频小组讨论中，有一次开发人员都分享了一个调试技巧:

In this video panel discussion with ember core developers, at one point the developers all share one debugging tip:

http://www.youtube.com/watch?v=L9OOMygo1HI

Tom Dale 特别解决了 Promise 中吞入异常的问题，并建议使用新的 Ember.RSVP.onerror 功能来调试 Promise 中的错误，否则这些错误会因为没有附加拒绝处理程序而未被报告.

Tom Dale specifically addresses the issue of swallowed exceptions inside promises and recommends use of the new Ember.RSVP.onerror feature for debugging errors inside promises which would have otherwise gone unreported because no rejection handler was attached.

我认为这是我问题的正确答案——尽管我还不知道如何使用 RSVP.onerror 回调(或在哪个 ember 中发布可用的回调)......

I think that is the correct answer to my question -- although I don't yet know how to use the RSVP.onerror callback (or in which ember releases its available) ...

这篇关于“大声"错误的可接受承诺模式?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！