2015-03-13 9 views
16

In meiner app verwende ich einen Abfangjäger alle http-Antwort-Fehler abzufangen, wie:AngularJS: benutzerdefinierte 404 Interceptor Griff - Antwort mit url

var response = function(response) { 
    if(response.config.url.indexOf('?page=') > -1) { 
    skipException = true; 
    } 
    return response; 
} 

var responseError = function(rejection) { 
    if (rejection.status === 401 || rejection.status === 403) { 
    /**/ 
    } 
    else if (rejection.status >= 500 || rejection.status === 0) { 
    /**/ 
    } 
    else if (rejection.status === 404 && !skipException) { 
    /**/ 
    } 
    else if (rejection.status === 404 && skipException) { 
    /**/ 
    } 
    else{ 
    /**/ 
    } 
    return $q.reject(rejection); 
}; 

Und wenn ich zu meinem Controller gehen (wenn meine getArticles Methode gibt einig Daten, nicht 404 - wenn Artikel Array leer ist) alles ist OK: 404 mit skipException == true wird abgefangen.

Aber wenn mein Artikel-Array leer ist, gibt der Server eine 404 zurück und wenn ich diesen Controller betrete, kann ich response.config.url nicht bekommen - keine Antwort wird abgefangen, aber warum? Ich dachte, der Abfangjäger würde alle Antworten auffangen.

$timeout(function() { 
     $scope.getArticles(); 
    }, 100); 

und $scope.getArticles hat einen solchen Code:

getDataService.getArticles($scope.pageNum).then(function(response) { 
/**/ 
}); 

Service:

var getEventsByScrollService = function(num) { 
    var deferred = $q.defer(); 
    $http.get(***, { 

    }) 
    .success(function(response) { 
     deferred.resolve(response); 
    }).error(function(err, status) { 
     if (status === 404){ 
     deferred.resolve([]); 
     } 
     else{ 
     deferred.reject(err); 
     } 
    }); 
    return deferred.promise; 
}; 

Wie kann ich auf die URL fangen 404 ist bedingt abhängig? Denn das:

if(response.config.url.indexOf('?page=') > -1) { 

Funktioniert nicht immer.

+2

Die Logik nach URL zu überprüfen, klingt falsch. Scheint, dass Sie verschiedene Services und/oder Service-Methoden für unterschiedliche Interceptor-Verhaltensweisen haben sollten. Die Service-Methoden sollten verschiedene Interzeptoren aufrufen, die verschiedene Fehler-Resolver aufrufen. Einer der Fehlerresolver sollte 404 behandeln und ein anderer sollte 404 ignorieren. Die Service-Methode sollte dies entscheiden. Kopplungslogik mit URLs klingt wie eine Verletzung von SoC. –

+0

können Sie vollständigen Code der Fehler-Antwort teilen – harishr

+1

@DaveAlperovich könnten Sie Beispiel mit verschiedenen Interzeptoren in meinem Fall bieten? – brabertaser19

Antwort

1

so ... ich habe es so gemacht:

if(rejection.config.url.indexOf('?page=') > -1) { 
     skipException = true; 
    } 
-1

Vom documentation:

Ein Antwortstatuscode zwischen 200 und 299 ein Erfolg Status betrachtet und in den Erfolg Rückruf führen, genannt zu werden.

Da der Server einen 404 zurückgibt, wird die responseError-Funktion aufgerufen. Leider ist der Parameter config nicht verfügbar, so dass Sie keine bedingte Logik basierend auf der dort angegebenen Anfrage-URL ausführen können.

1

In der "Antwort" Sie shoud Antwort url überprüfen, response.config.url nicht .. etwas wie folgt aus:

var response = function(response) { 
    if(response.url.indexOf('?page=') > -1) { 
     skipException = true; 
    } 
    return response; 
} 

auf der Ansprechschwelle Sie die config

2

nicht haben Sie können Restangular überprüfen, könnte für Ihre Zwecke nützlich sein. Es hat gute Interceptor-Methoden eingebaut. Ob es wirklich gut für Sie ist, hängt davon ab, ob Sie eine RESTful-API verwenden oder nicht. https://github.com/mgonto/restangular

2

In dem Bemühen, mehr wartbar und erweiterbar auf jeden $ http-Service-Aufruf zu sein, man dies tun könnte:

// Service call 
$http.get({url:'/?page=', ignoreErrors: true}) 

// Interceptor 
if(rejection.status === 404 && !rejection.config.ignoreErrors) { 

} 
Verwandte Themen