Я использую $http
AngularJs, и я не уверен, как использовать возвращенное обещание и обрабатывать ошибки.
У меня есть такой код:
$http
.get(url)
.success(function(data) {
// Handle data
})
.error(function(data, status) {
// Handle HTTP error
})
.finally(function() {
// Execute logic independent of success/error
})
.catch(function(error) {
// Catch and handle exceptions from success/error/finally functions
});
Это хороший способ сделать это или есть более простой способ?
success()
,error()
и вfinally()
сочетании сcatch()
? Или мне нужно использоватьthen(successFunction, errorFunction).catch(exceotionHandling).then(cleanUp);
success
иerror
(предпочитают.then
и.catch
вместо этого, вы можете (и должны) опуститьerrorFunction
от.then
использования переменного тока ,catch
как в моем коде выше).success
/error
? Также мой Eclipse выходит из себя.catch(
, когда видит , поэтому я использую["catch"](
сейчас. Как я могу приручить Eclipse?.success
и.error
, $ HTTP возвращает $ Q обещание с добавлением изsuccess
иerror
обработчиков - однако, эти обработчики не цепь и следует избегать , если / когда это возможно. В общем - если у вас есть вопросы, лучше задавать их как новый вопрос, а не как комментарий к старому.Забудьте об использовании
success
иerror
методе.Оба метода устарели в angular 1.4. По сути, причина устаревания заключается в том, что они не подходят для цепочки , так сказать.
В следующем примере я попытаюсь продемонстрировать, что я имею в виду,
success
иerror
не использовать цепочки . Предположим, мы вызываем API, который возвращает объект пользователя с адресом:Пользовательский объект:
Вызов API:
Что произошло?
Поскольку
success
иerror
возвращает исходное обещание , то есть то, которое возвращает$http.get
, объект, переданный в обратный вызов,then
представляет собой весь пользовательский объект, то есть тот же самый ввод для предыдущегоsuccess
обратного вызова.Если бы мы связали два
then
, это было бы менее запутанно:источник
success
иerror
будут только добавлены к немедленному возвращению на$http
вызов (не прототип), поэтому , если вы звоните другой способ посыла между ними (как, обычно называютreturn $http.get(url)
завернутые в базовой библиотеке, но позже решили переключить счетчик в вызов библиотеки с помощьюreturn $http.get(url).finally(...)
), то у вас больше не будет этих удобных методов.Я думаю, что предыдущие ответы верны, но вот еще один пример (только fyi, success () и error () устарели в соответствии с главной страницей AngularJS :
источник
Какой тип детализации вы ищете? Обычно вы можете обойтись:
Я обнаружил, что "finally" и "catch" лучше использовать при объединении нескольких обещаний.
источник
loading = false
).catch()
методомВ случае Angular $ http функции success () и error () будут иметь развернутый объект ответа, поэтому подпись обратного вызова будет похожа на $ http (...). Success (function (data, status, headers, config))
для then () вы, вероятно, будете иметь дело с необработанным объектом ответа. например, опубликованный в документе AngularJS $ http API
Последний .catch (...) не понадобится, если в предыдущей цепочке обещаний не возникнет новая ошибка.
источник
Я делаю это, как предлагает Брэдли Брейтуэйт в своем блоге :
Это довольно стабильно и безопасно, и если у вас есть другие условия для отклонения обещания, вы всегда можете отфильтровать свои данные в функции успеха и вызвать
deferred.reject(anotherReason)
причину отказа.Как предположил Райан Вайс в комментариях , это может оказаться бесполезным, если вы, так сказать, немного не поиграете с ответом.
Поскольку
success
иerror
устарели с версии 1.4, возможно, лучше использовать обычные методы обещанийthen
иcatch
и преобразовать ответ в этих методах и вернуть обещание этого трансформированного ответа.Я показываю один и тот же пример с обоими подходами и третьим промежуточным подходом:
success
иerror
подход (success
иerror
вернуть обещание ответа HTTP, поэтому нам нужна помощь$q
для возврата обещания данных):then
иcatch
подход (это немного сложнее проверить из-за выброса):Однако есть половинчатое решение (таким образом вы можете избежать
throw
и в любом случае вам, вероятно, придется использовать$q
для имитации поведения обещания в ваших тестах):Любые комментарии и исправления приветствуются.
источник
success()
иerror()
не вернет новое обещание, как этоthen()
делает. С помощью$q
мы заставляем нашу фабрику возвращать обещание данных вместо обещания ответа HTTP.