Я использую библиотеку 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, используемой в коде приложения в этом контексте?