Angular.js: Le service $http n'appelant pas le rappel d'erreur sur 400

Créé le 8 mai 2013 · 26Commentaires · Source: angular/angular.js

Version : 1.1.4

createNewWall: function(wall, successCallback, errorCallback) {
    return $http.post($rootScope.baseAppsAPI + '/walls', null, {
       params: wall
    }).success(function(data, status) {
       return successCallback.call(this, data);
    }).error(function(data) {
       return errorCallback.call(this, data);
    });
}

J'ai vérifié que la fonction angulaire isSuccess fonctionne correctement. Je l'ai fait en l'ajoutant à l'objet window et en vérifiant que le code ci-dessous (placé dans mon rappel de réussite ) a entraîné l'appel du rappel d'erreur.

if (window.isSuccess(status)) {
   return successCallback.call(this, data);
} else {
  return errorCallback.call(this, data);
}

Une idée de la cause du problème ? Quelque chose ne va pas avec les promesses $http qui ne sont pas correctement rejetées/résolues ?

Source

lsiv568

👍1

Commentaire le plus utile

Pour moi, la réponse de @ lsiv568 a fait l'affaire. C'est un peu bizarre au début mais vous devez retourner une promesse rejetée manuellement lorsque vous construisez un intercepteur d'erreurs ( source ).

.factory('myInterceptor', function($q) {
  return {
    response: function (response) { return response; },
    responseError: function(response) {
      // do stuff or
      return $q.reject(response);
    }
  };
});

chmanie le 28 mai 2014

👍24 🎉2 ❤1

Tous les 26 commentaires

Je suis confronté au même problème. La façon dont vous avez fermé le problème peut signifier que je peux faire quelque chose de mal, etc. Pouvez-vous s'il vous plaît partager votre solution ? Impossible de trouver ça nulle part.

rtpm le 13 mai 2013

Robert.,

J'ai fermé le problème parce que le problème a disparu (miraculeusement) après que j'ai
apporté quelques modifications à mon service. Cependant, il semble revenir
par intermittence. Donc, je ne sais plus si c'est un problème de mon côté ou un
vrai problème avec angulaire. Si vous le souhaitez, je peux rouvrir le problème et vous pouvez
ajoutez-y votre problème? Est-ce que ça marche pour toi?

Le lundi 13 mai 2013 à 9h13, Robert [email protected] a écrit :

Je suis confronté au même problème. La façon dont vous avez clos le problème peut signifier que je
peut faire quelque chose de mal, etc. Pouvez-vous s'il vous plaît partager votre solution ? Je ne peux pas
trouve ça n'importe où.
-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/angular/angular.js/issues/2609#issuecomment -17810417
.

Avec respect,
Louis W. Sivillo

lsiv568 le 13 mai 2013

Comme indiqué ci-dessus, je rouvre ce problème car il se produit par intermittence. rtpm, veuillez inclure votre cas d'utilisation/toute information supplémentaire pouvant aider à identifier le problème

lsiv568 le 14 mai 2013

Robert,
Merci d'avoir envoyé ça.

J'avais un intercepteur http que j'avais écrit pour l'authentification de base qui ne rejetait pas la promesse sur les erreurs de réponse.

lsiv568 le 14 mai 2013

👍13

Merci à vous les gars. J'ai eu le même problème.

se-panfilov le 5 juil. 2013

+1 m'arrive lorsque le serveur renvoie 401

sinelaw le 3 janv. 2014

+1
La fonction de rappel ne fonctionne pas pendant que le serveur renvoie le code d'état 401.

hari-s le 3 févr. 2014

Des progrès à ce sujet ? Face au même problème avec un 400.

timsuchanek le 15 mai 2014

.factory('myInterceptor', function($q) {
  return {
    response: function (response) { return response; },
    responseError: function(response) {
      // do stuff or
      return $q.reject(response);
    }
  };
});

chmanie le 28 mai 2014

👍24 🎉2 ❤1

Face au même problème avec un 400..
Mais pourquoi le problème est-il clos, existe-t-il une solution spécifique à ce problème ?

senthil1216 le 12 juin 2014

Je suis également confronté à ce problème avec l'erreur 400. Ce problème a-t-il été résolu ? Si oui, dans quelle version ?

yaronsch le 22 juin 2014

Je rencontre le même problème avec toutes les erreurs > 299. J'utilise Restangular avec un intercepteur de réponse personnalisé, mais j'obtiens l'erreur avec le service $http prêt à l'emploi, à l'exception d'un en-tête de jeton CSRF. (J'ai quand même essayé de rejeter manuellement l'objet différé depuis Restangular, mais comme prévu, cela n'a rien changé.)

nick-merrill le 29 juin 2014

Je rencontre également ce problème, pouvons-nous le rouvrir ?

dlabey le 1 juil. 2014

Le problème signalé dans le problème d'origine était dû à un intercepteur personnalisé ne gérant pas correctement les conditions d'erreur (une promesse n'a pas été rejetée). Si quelqu'un rencontre toujours un problème, il s'agit probablement de la même situation - veuillez vérifier que vous n'avez pas d'intercepteurs personnalisés buggés. Si vous pensez toujours que quelque chose ne va pas du côté d'AngularJS, veuillez fournir un scénario de reproduction _minimal, en direct_ (idéalement en utilisant http://plnkr.co/ mais tout autre outil similaire fera l'affaire).

pkozlowski-opensource le 1 juil. 2014

@pkozlowski-opensource Merci, je peux en effet confirmer que c'était mon problème (d'oh).

dlabey le 1 juil. 2014

Il devrait y avoir une note dans les documents angulaires à ce sujet - je ne savais pas que j'ignorais complètement le comportement de la promesse $ http en implémentant mon intercepteur.

twig2let le 2 sept. 2014

👍3

J'ai également rencontré ce problème et j'ai eu un intercepteur que j'ai regardé encore et encore car il avait effectivement le bon retour. J'ai enfin trouvé le coupable. Si vous utilisez plusieurs appels à succès/erreur ou que vous devez vous assurer qu'ils renvoient également la bonne chose :) les rappels de réussite doivent renvoyer la réponse modifiée tandis que les rappels d'erreur doivent renvoyer un rejet avec $q.reject, tout comme l'intercepteur.