Приемлемый шаблон обещания для ошибок "LOUD"?

Я использую библиотеку RSVP, распространяемую внутри Ember.js, и я пытаюсь выяснить правильную модель для сообщения фатальных ошибок внутри обещания - особенно я хочу сообщить о чем-то, что почти наверняка является результатом программирования ошибка из-за неправильного использования api, и я хочу сделать это с помощью LOUD. Я новичок в promises и javascript в целом, надеюсь, этот вопрос имеет смысл

Вот простой пример (в 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 некорректным образом

Я столкнулся с идеей использования setTimeout в обработчике отклонения, чтобы гарантировать, что ошибка повышается откуда-то, даже если вызывающий не прикрепляет обработчик ошибок к обещанию

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)

Является ли разумная практика прикреплять такой обработчик ошибок по умолчанию к обещанию, прежде чем возвращать его из моего обещанияReturningApi? Это позволило бы мне заставить stacktrace, когда вызывающий делает что-то, что не может работать, даже несмотря на то, что stacktrace будет немного странным, что может сделать вещи немного легче начать с...

Несмотря на то, что я назвал пример обещания, возвращающего функцию, вызовом "api" - я должен добавить, что я не пишу код рамки - это скорее всего в приложении. Если doAsync - это реальная функция, то в моей версии реального мира она скорее всего будет поступать с внешней стороны с помощью api-а-а-а-а-а, поэтому кажется, что я буду злоупотреблять ею, пока Я узнаю об этом... Значит, я мог бы сделать шаблон похожим на это

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)

Я думаю, что это то, что вы делаете исключение, которое должно быть выбрано откуда-то в любое время, когда сам вызов вызова асинхронной функции вызывает исключение - такое исключение почти наверняка будет поднято во время фазы проверки аргумента асинхронного вызова, чаще всего будет результатом того, что код моего приложения передается во что-то, что не имеет никакого смысла, - и я хочу узнать об этом, как только смогу. Кажется ли это разумной моделью, чтобы помочь в отладке promises, используемой в коде приложения в этом контексте?

Ответы

model: function(params) {
  var promise = Ember.Deferred.create();
  var successCallback = function(resp) {
    promise.resolve(resp);
  };

  var errorCallback = function(err) {
    promise.reject(err);
  };

  var thenable = promise.then(function(resp) {
    if (resp.isError) {
      throw new Error(resp.errorMessage);
    } else {
      return resp;
    }
  });

  // some api that takes a callback
  this.callApi(params, successCallback, errorCallback);

  return thenable;
},

 successCallback({data: 'foo'});

 successCallback({isError: true, errorMessage: 'Response data is wrong'});

 errorCallback('Incorrect use of API');