›

NSURLRequest et timeout...

Alf1996Alf1996 Membre
dans Objective-C, Swift, C, C++ #1
Bonjour,

Jusqu'à  présent, j'utilisais "[font=arial,helvetica,sans-serif]NSURLRequest requestWithURL"[/font], et puis je me suis posée la question de ce qui se passait si on perd le réseau avant d'avoir obtenu le retour des données... Globablement j'ai assez peu de données à  récupérer, et je considère que si ce n'est pas terminé après une dizaine de secondes, c'est qu'il y a un problème... En fouillant dans la doc, j'ai trouvé que le timeout par défaut est de 60 secondes, et qu'on peut choisir une autre valeur en utilisant "[font=arial, helvetica, sans-serif]NSURLRequest requestWithURL: cachePolicy: timeoutInterval:". Au cas où on atteint le timeout, je suppose qu'on récupère error non nil ? Si c'est le cas, comment gérez vous les erreurs ? Est-t-il préférable de préciser l'erreur qui s'est produite ? ou simplement un message "générique" du type "Erreur, problème de réseau, veuillez réessayer plus tard..."[/font]

[font=arial, helvetica, sans-serif]Merci de vos conseils...[/font]

Réponses

  • samirsamir Membre
    #2
    Bonsoir,



    Généralement on a deux erreurs qu'ils faut gérer, pas de connexion internet et le cas ou y a une connexion internet et le serveur ne répond pas ( un time out), dans les deux cas un message d'erreur est obligatoire pour informer l'utilisateur.
  • Alf1996Alf1996 Membre
    #3
    Merci Samir.

    Pour l'absence de connexion réseau, je la teste avant d'envoyer ma requête, et en cas de non disponibilité, je fais un message, mais, tu veux dire que c'est une obligation (imposée par Apple) de signaler à  l'utilisateur que l'on a obtenu un timeout ? ou on peut dire qu'il y a eu un problème de connexion tout simplement, sans détailler le type de problème. Un truc du genre "problème de réseau, pas de données importées" ?
  • AliGatorAliGator Membre, Modérateur
    #4
    Il y a pour moi 3 types d'erreur en général :

    - erreur réseau : pas de réseau, timeout...

    - erreur serveur : erreur 404, 500...

    - erreur applicative : le serveur retourne une réponse (genee JSON) te disant qu'il y a un problème (par exemple tu demandés à  ton WebService de stocker un objet mais l'objet envoyé n'est pas complet, il te retourne donc un JSON décrivant l'erreur, etc)



    Chaque type d'erreur est à  traiter différemment selon les cas et la situation, c'est à  toi d'adapter...
  • muqaddarmuqaddar Administrateur
    #5
    'AliGator' a écrit:


    Il y a pour moi 3 types d'erreur en général :

    - erreur réseau : pas de réseau, timeout...

    - erreur serveur : erreur 404, 500...

    - erreur applicative : le serveur retourne une réponse (genee JSON) te disant qu'il y a un problème (par exemple tu demandés à  ton WebService de stocker un objet mais l'objet envoyé n'est pas complet, il te retourne donc un JSON décrivant l'erreur, etc)



    Chaque type d'erreur est à  traiter différemment selon les cas et la situation, c'est à  toi d'adapter...




    Erreur serveur 404 ou 500, c'est dans le cas où le serveur est actif.

    Et si le serveur est éteint ou en redémarrage (hard) ? On est dans une erreur réseau ou serveur ? On doit avoir un timeout non ?
  • Alf1996Alf1996 Membre
    #6
    'AliGator' a écrit:


    Il y a pour moi 3 types d'erreur en général :

    - erreur réseau : pas de réseau, timeout...

    - erreur serveur : erreur 404, 500...

    - erreur applicative : le serveur retourne une réponse (genee JSON) te disant qu'il y a un problème (par exemple tu demandés à  ton WebService de stocker un objet mais l'objet envoyé n'est pas complet, il te retourne donc un JSON décrivant l'erreur, etc)



    Chaque type d'erreur est à  traiter différemment selon les cas et la situation, c'est à  toi d'adapter...




    Merci bien, je vais me mettre de ce pas à  la gestion d'erreurs...
  • AliGatorAliGator Membre, Modérateur
    #7
    'muqaddar' a écrit:


    Erreur serveur 404 ou 500, c'est dans le cas où le serveur est actif.

    Et si le serveur est éteint ou en redémarrage (hard) ? On est dans une erreur réseau ou serveur ? On doit avoir un timeout non ?
    Bah par définition d'après ce que j'ai mis plus haut oui, si le serveur est éteint ou inaccessible, on ne peut le savoir qu'après un timeout. Je l'ai pas cité (c'était inclus dans les points de suspension) mais bien sûr une erreur de DNS (tu essayes d'accéder à  une adresse qui n'existe pas, genre http://fjdkslqfjdkhfgrmijkcslmv.fdsjkl) fait aussi partie des erreurs "réseau", puisque pour moi les erreurs réseau regroupent toutes les erreurs qui font que le serveur demandé n'est pas joingnable.



    Erreur serveur pour moi c'est que le serveur est accessible, mais te répond une erreur HTTP (donc code de retour autre que 2xx). Les plus courants étant 404 ou 500, mais tous les 4xx ou 5xx y passent en fait. Dans ce cas tu n'as que les infos du header HTTP pour savoir le type d'erreur et ce qui s'est passé (400 Bad Request, 404 Not Found, ...?)



    Erreur applicative c'est que le serveur est accessible, et te répond correctement, mais c'est juste que ce qu'il se trouve te répondre, c'est un JSON indiquant une erreur parce que tu l'as prévu comme ça côté applicatif (par exemple si tu demandes à  ton WebService d'ajouter dans ta base un vin de 2030 alors que l'année n'existe pas encore). On appelle parfois cela une "erreur logique" dans le sens où c'est la validation côté applicatif qui détermine que la demande faite par le WebService n'est pas "logique", ne respecte pas les critères, etc.



    Après tout dépend comment tu as configuré ton serveur Web. Si quand tu demandes à  ton WebService l'objet d'id 7 mais que cet objet n'existe pas, tu peux décider côté WebService de retourner une erreur 404 (puisque la ressource demandé, à  savoir l'objet d'id 7, n'est pas trouvé). Ou choisir que ton WebService retourne un 200 OK, mais avec un JSON de type { errorCode: 7, message:"ID not found" } si tu veux que ton WebService ait des codes d'erreur dédiés à  ce genre de trucs. Selon le cas cela ne tombera alors pas dans la même catégorie d'erreur, puisque dans un cas ton code va devoir regarder le statusCode de ta réponse HTTP, dans l'autre cas il va devoir regarder le body de la requête, l'interpréter comme du JSON, traiter le cas où le JSON est invalide et ne peut être décodé, et remonter la valeur de la clé "errorCode" de ce JSON...



    De même si tu oublies un paramètre dans l'appel d'une méthode tu peux décider que ton serveur retourne une erreur "400 Bad Request" et traiter cela alors côté client comme une erreur serveur (cela a tout à  fait son sens en fait), ou décider que ton serveur retourne un "200 OK" avec un JSON d'erreur dans son body, qu'il te faudra décoder pour extraire l'erreur, comme toute erreur que j'appelle applicative.
  • muqaddarmuqaddar Administrateur
    février 2013 modifié #8
    Globalement, je fais comme ça actuellement (erreurs serveur 404 ou 500) + erreurs JSON sur les objets.


    'AliGator' a écrit:


    Bah par définition d'après ce que j'ai mis plus haut oui, si le serveur est éteint ou inaccessible, on ne peut le savoir qu'après un timeout.




    Faudra que je vérifie comment je gère celle-ci.
  • LarmeLarme Membre
    #9
    Personnellement, j'essaierais d'être le plus précis possible, et de toujours en informer l'utilisateur. Apple préconise d'informer l'utilisateur (cas sur les NSStreams)

    Maintenant, l'utilisateur lambda n'a pas forcément les connaissances nécessaires pour comprendre les messages d'erreurs...

    Du coup, je pense qu'il faut diviser les erreurs ainsi :

    - Pas de connexion web

    - Serveur inaccessible

    - Erreur lors du chargement de la page/information/dialogue avec le serveur dont le message est erroné...
  • AliGatorAliGator Membre, Modérateur
    #10
    Oui ce que j'ai présenté sur ma vision de la sectorisation des erreurs (réseau/serveur/applicatif) est plutôt un découpage que je fais sur le traitement des données dans mon code. Je dois les gérer à  3 endroits différents : avec SCReachability d'un côté ou les timeouts, avec l'errorcode de la réponse d'un autre côté, et un décodage du JSON puis une ventilation des erreurs au cas par cas pour les erreurs applicatives (puisque chaque requête de mon WebService a un but différent dont les messages d'erreur correspondants seront en général propres à  chaque méthode de mon WS, en général)

    Donc ça c'est pour la partie code, la partie "à  quel endroit doit-je mettre du code pour traiter les différents cas d'erreur"



    Mais il y a aussi un découpage différent au niveau fonctionnel, pour savoir quand je remonte une alerte à  l'utilisateur ou pas, et si oui quel genre de message je mets dedans.
    • Quand il n'y a pas de réseau ou timeout, je met en général un message comme quoi il y a une mauvaise connexion réseau (ou pas de réseau du tout)
    • Quand il y a une erreur 4xx ou 5xx, c'est en général soit dû à  un problème de codage dans mon application (j'ai appelé une méthode de mon WebService avec des paramètres incohérents, j'ai oublié un paramètre...) en général ça ne devrait pas arriver, donc sinon c'est plus probablement parce que le serveur a un souci (il est en 503 car en cours de maintenance, par exemple), donc je met plutôt un message du style "le serveur est indisponible pour l'instant, veuillez réessayer plus tard"
    • Quand il y a une erreur applicative, du style "vous n'avez pas les autorisations pour supprimer cet objet" ou "impossible de créer un vin daté dans le futur" ou "ce nom d'utilisateur est déjà  utilisé, veuillez en choisir un autre", bah en général j'ai du cas par cas, puisque chaque méthode de WebService a une liste des erreurs qu'elle peut potentiellement me retourner (pour ma méthode de création de compte ça sera "login déjà  pris", "login ou mot de passe vide", "email incorrect", des choses comme ça par exemple, mais ça reste une liste finie). Quitte à  remonter dans mon JSON d'erreur le message à  afficher (et dans ce cas ne pas oublier l'i18n, donc soit retourner non pas le message mais la clé du Localizable.strings à  afficher, soit faire en sorte de passer la locale de l'utilisateur à  l'appel du WebService ou via un Cookie, de sorte que le serveur retourne l'erreur dans la bonne langue)
  • LarmeLarme Membre
    #11
    Oui, en effet, Ali, je reprenais un peu ton idée, mais du point de vue utilisateur...

    Et du coup, par rapport à  mon message initial je rajouterais (le terme message, car je parlais plus du message qui sera envoyé à  l'utilisateur), pour être plus précis avec ce point de vue :
    [font=helvetica, arial, sans-serif]Du coup, je pense qu'il faut diviser les messages erreurs ainsi :[/font]

    [font=helvetica, arial, sans-serif]- Pas de connexion web[/font]

    [font=helvetica, arial, sans-serif]- Serveur inaccessible[/font]

    [font=helvetica, arial, sans-serif]- Erreur lors du chargement de la page/information/dialogue avec le serveur dont le message est erroné...[/font]
Connectez-vous ou Inscrivez-vous pour répondre.