Gestion des erreurs serveur
muqaddar
Administrateur
Salut,
J'aimerais connaà®tre votre politique maison pour traiter les erreurs serveur lors de téléchargements par lots.
Par exemple, on peut imaginer 2 cas pour commencer:
1) server indisponible
2) erreur de code sur le serveur
Si dans le cas 1), le serveur est mort, on tue la boucle. Il y a peu de chance que le serveur soit OK pour la requête suivante. Ainsi, l'utilisateur n'aura pas 15 fois le même message d'erreur à la suite...
Mais dans le cas 2), on peut imaginer un problème avec une ressource (bug code), mais pas la suivante, qui renverrait une erreur 500. Dans ce cas, il faut ne pas tuer les autres requêtes... mais on peut aussi imaginer que toute la liste va foirer, et dans ce cas, il faudrait tuer la boucle.
Côté serveur, je peux lever des exceptions pour envoyer des réponses "KO" en Json par exemple ou autre chose si il y a un problème de code.
Bref, il y a plusieurs cas à traiter.
Mon principal problème est de ne pas faire boucler une erreur récurrente sur chaque requête et savoir quand terminer l'OperationQueue.
J'aimerais connaà®tre votre politique maison pour traiter les erreurs serveur lors de téléchargements par lots.
Par exemple, on peut imaginer 2 cas pour commencer:
1) server indisponible
2) erreur de code sur le serveur
[color=#6f43a4][color=#34595d]failure[/color][color=#000000]:^([/color]NSURLRequest[color=#000000] *request, [/color]NSHTTPURLResponse[color=#000000] *response, [/color]NSError[color=#000000] *error)[/color][/color]<br />
{<br />
[color=#3f277d]NSLog[/color]([color=#d1342a]@"error code : %d"[/color], [error [color=#3f277d]code[/color]]);<br />
<br />
[color=#b9369d]if[/color] ([error [color=#3f277d]code[/color]] == -[color=#2537d1]1004[/color]) {<br />
[color=#34595d][color=#000000] [[/color][color=#b9369d]self[/color][color=#000000] [/color]notifyWithSuccess[color=#000000]:[/color][color=#b9369d]NO[/color][color=#000000] [/color]title[color=#000000]:[/color][color=#784a32]_T[/color][color=#000000]([/color]SERVER_UNAVAILABLE[color=#000000]) [/color]message[color=#000000]:[/color][color=#784a32]_T[/color][color=#000000]([/color]PLEASE_TRY_LATER[color=#000000])]; [/color][/color]<br />
[color=#3f277d][color=#000000] [queue [/color]cancelAllOperations[color=#000000]];[/color][/color]<br />
}<br />
[color=#b9369d]if[/color] ([error [color=#3f277d]code[/color]] == -[color=#2537d1]1011[/color]) { [color=#008123]// 500[/color]<br />
[color=#34595d][color=#000000] [[/color][color=#b9369d]self[/color][color=#000000] [/color]notifyWithSuccess[color=#000000]:[/color][color=#b9369d]NO[/color][color=#000000] [/color]title[color=#000000]:[/color][color=#784a32]_T[/color][color=#000000]([/color]SERVER_ERROR[color=#000000]) [/color]message[color=#000000]:[/color][color=#784a32]_T[/color][color=#000000]([/color]PLEASE_TRY_LATER[color=#000000])];[/color][/color]<br />
}<br />
}<br />
Si dans le cas 1), le serveur est mort, on tue la boucle. Il y a peu de chance que le serveur soit OK pour la requête suivante. Ainsi, l'utilisateur n'aura pas 15 fois le même message d'erreur à la suite...
Mais dans le cas 2), on peut imaginer un problème avec une ressource (bug code), mais pas la suivante, qui renverrait une erreur 500. Dans ce cas, il faut ne pas tuer les autres requêtes... mais on peut aussi imaginer que toute la liste va foirer, et dans ce cas, il faudrait tuer la boucle.
Côté serveur, je peux lever des exceptions pour envoyer des réponses "KO" en Json par exemple ou autre chose si il y a un problème de code.
Bref, il y a plusieurs cas à traiter.
Mon principal problème est de ne pas faire boucler une erreur récurrente sur chaque requête et savoir quand terminer l'OperationQueue.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Et côté client:
Et donc je détruit la boucle uniquement avec une 500 (problème de code ?) mais pas avec une 404 (resource introuvable). Je pense que c'est la meilleure approche.
C'est quel langage côté serveur ?
J'ai la flemme de tout ré-apprendre
C'est comme du PHP, sans les $ et sans point virgule. :-)
Du code Ruby fait plus propre à lire.
Bon je dis ça, mais ça fait 5 ans que j'en fais, et je regrette pas, surtout au niveau productivité.