2015-10-16 1 views
9

Les nouveaux js vont chercher API échoue la promesse si la requête échoue (400):N'y a-t-il vraiment aucun moyen d'obtenir le corps de la réponse à partir d'une requête js fetch échouée?

fetch(uri).catch(function(err) { 
    console.log(err); 
}); 

Est-il vraiment aucun moyen d'obtenir le corps de la réponse lorsque cela se produit? par exemple. pour vérifier un code d'erreur.

EDIT: J'ai créé un violon js: https://jsfiddle.net/4x4xLwqo/ qui appelle ce critère d'évaluation de mockbin: http://mockbin.org/bin/d87acbb0-526e-4d66-aea4-b827d9c35031/view

EDIT 2: jsFiddle mis à jour pour utiliser un meilleur critère d'évaluation: https://jsfiddle.net/4x4xLwqo/2/

Répondre

9

fetch ne rentrerai pas dans catch si il rencontre une erreur HTTP. Vous pouvez gérer cela avec un then régulier.

De MDN:

Une fetch() promesse rejettera avec un TypeError lorsqu'une erreur de réseau est rencontré, même si cela signifie généralement des problèmes d'autorisation ou similaire - 404 ne constitue pas une erreur de réseau, par exemple. Une vérification précise d'un succès fetch() consisterait à vérifier que la promesse a été résolue, puis à vérifier que la propriété Response.ok a la valeur true.

Et un exemple d'accompagnement, ainsi de MDN:

fetch('flowers.jpg').then(function(response) { 
    if(response.ok) { 
    response.blob().then(function(myBlob) { 
     var objectURL = URL.createObjectURL(myBlob); 
     myImage.src = objectURL; 
    }); 
    } else { 
    console.log('Network response was not ok.'); 
    } 
}) 
.catch(function(error) { 
    console.log('There has been a problem with your fetch operation: ' + error.message); 
}); 
+0

Vous avez déjà essayé? Je me retrouve dans le bloc catch d'un 400 – grahamrhay

+0

voir le jsfiddle ci-dessus – grahamrhay

+1

@grahamrhay Vous demandez un contenu non sécurisé ('" http: // mockbin "') depuis une page sécurisée ('" https: // jsfiddle "') . Vous ne pouvez pas faire cela. Fetch est en erreur avant même de demander au serveur. De même, je ne vois pas les en-têtes de contrôle d'accès dans les réponses Mockbin. S'il n'y a pas d'accès, encore une fois, ce n'est pas une erreur de serveur, c'est une erreur de connexion. Si vous possédiez deux (sous) domaines TLS (ou deux 100% non sécurisés) et chacun des en-têtes de contrôle d'accès correctement servis (ou il n'y avait qu'un transfert de données unidirectionnel et le serveur de données avait les en-têtes d'accès), Cela devrait fonctionner correctement. – Norguard