[AJAX] Que faire d'une erreur ?

[Ter Rowan]

hello les gens

je viens de me faire un petit système en ajax (via jquery) et je me pose la question de la gestion d'erreur :

le navigateur fait une demande au serveur qui lui renvoie une erreur...

Qu'en feriez vous de cette erreur ?

Un message au joueur et c'est tout ? ?
Un log en bdd et dans ce cas comment ? (en renvoyant une requete ajax ? apache est capable de loguer coté serveur ?)

bref je sais pas quoi en faire de mon erreur :cogne:

[Xenos]

Salut,

J'enregistrerai une notification dans la console déjà. Ensuite, si l'erreur et la requête le permette, j'en renvoie une nouvelle (par exemple, une erreur de latence réseau).
Sinon
* s'il s'agit d'une commande, j'informe explicitement l'utilisateur que cette commande n'est pas passé, et je lui propose de nouvelles options. Par exemple, si le joueur a lancé une attaque sur une ville, je l'informe qu'une erreur réseau n°X a empêché l'ordre d'être envoyé à son armée. Il peut alors: relancer l'ordre, changer l'ordre, abandonner cet ordre. Le "X" est un lien vers le détail complet de l'erreur.
* S'il ne s'agit pas d'une commande, c'est à dire s'il s'agit d'une requête AJAX qui n'a pas été explicitement demandée, alors je "grise" la zone où le résultat aurait du être affiché et je relance la requête (ça, c'est s'il y a déjà des données qui avaient été reçues avant, aka l'AJAX devait mettre ces données à jour donc je les grise pour indique que les données affichées datent un peu), soit je met un logo de chargement là où le résultat aurait du s'afficher.

Si l'erreur persiste, je retente.
Si les données affichées sont vraiment vieilles (j'ai fait plein d'essais AJAX et je n'arrive pas à mettre les données à jour car je n'ai pas de réponse valide), alors j'indique explicitement à l'utilisateur que ces données sont franchement vieilles (mais je ne l'empêche pas de continuer à jouer pour autant, il se peut que le joueur soit en train de réfléchir sur papier à la meilleure stratégie de jeu et qu'il ait donc coupé son 4G mobile pendant ce temps de réflexion).


TL;DR
Si l'utilisateur a demandé quelque chose, je lui réponds explicitement que ça a foiré et je lui propose de nouvelles options.
Si l'utilisateur n'a rien demandé (AJAX "background"), je ne l'informe pas, mais si besoin, j'indique que la page est un peu vieille (pas de pop-up si l'utilisateur n'en n'attends pas).
Il est inutile de dire juste "Une erreur a eu lieu.": la plupart des gens s'en foutent, ils attendent surtout les solutions pour corriger l'erreur.

Logger l'erreur peut être intéressant. En ce cas, je stockerai l'erreur en mémoire vive (aka, dans un tableau Javascript), et je l'enverrai via une autre requête AJAX. Si celle-ci échoue aussi, je le log dans cette mémoire tampon, et j'attends au moins une minute. Tu peux aussi stocker les erreurs javascript dans un cookie ou en local sur l'ordinateur client, et les envoyer à la prochaine requête "classique" (aka, visite de page, pas AJAX).

[SorenS]

Un log en bdd et dans ce cas comment ? (en renvoyant une requete ajax ? apache est capable de loguer coté serveur ?)

Pourquoi ne serait-il pas capable ? Tu exécute bien du php via ta requête ajax. Dans ton controler tu lui dis de loguer.

Pour l'affichage tout dépend l'erreur retournée et l'action. Mais si ça vient d'une action du joueur faut bien lui dire ce qui s'est passé suite à son clic quand même je pense.

[Xenos]

Le log en BDD est foireux si l'erreur AJAX est du type "pas de connexion internet"

[Ter Rowan]

Un log en bdd et dans ce cas comment ? (en renvoyant une requete ajax ? apache est capable de loguer coté serveur ?)

Pourquoi ne serait-il pas capable ? Tu exécute bien du php via ta requête ajax. Dans ton controler tu lui dis de loguer.

Pour l'affichage tout dépend l'erreur retournée et l'action. Mais si ça vient d'une action du joueur faut bien lui dire ce qui s'est passé suite à son clic quand même je pense.

Hello quand je dis apache est capable de loguer, c est du genre sollicitation d un script qui n'existe pas ou qui n est pas autorisé, du coup pas de php qui logue en

Sinon oui, bien sur j informerai l utilisateur , les concepts de Xenos sont intéressants , je me pose plus la question pour les infos coté développeur

[Sephi-Chan]

Il faudrait être plus concret dans les requêtes en question. :p

[Xenos]

Quelques idées génériques en attendant:
- Une timelime avec un point pour chaque erreur
- Variation de la teinte de couleur (couleur du point sur la timeline par exemple, ou couleur de la ligne dans un tableau de log des erreurs) en fonction de la gravité de l'erreur
- Variation de la luminosité en fonction de la récurrence de l'erreur (noir = cette erreur n'a eu lieu qu'une fois, couleur claire = cette erreur revient souvent)
- Affichage des erreurs par type, par gravité, par récurrence, ou par joueur
- Système de calcul de l'importance de l'erreur, à l'image du système de calcul de l'importance des failles (OWASP), en utilisant des facteurs comme la récurrence de l'erreur en général, le nombre de joueurs touchés, la gravité des conséquences de l'erreur, la récupérabilité des données (les données suite à l'erreur sont-elles perdues ou peuvent-elle être renvoyées par le client/recalculées par le serveur?)


Ce sont des pistes génériques, qui pourraient s'appliquer à tout type d'erreur dans tout projet informatique (erreurs AJAX, erreurs coté serveur, erreurs réseau,...).

[Argorate]

Ça dépend de l'erreur.

Si c'est une erreur parce que le joueur cheat en trifouillant le JS, tu en as rien à faire, pourquoi perdre des ressources pour un cas pareil? (tu peux éventuellement logé les tentative de cheat ceci dit)

Si c'est une erreur du programmeur (code serveur), tu dois déjà avoir ce qui faut pour log j'imagine, du coup rien à faire de plus.

Enfin, Si c'est une erreur utilisateur, (bien que ce soit mieux de vérif en JS pour évité une AJAX dans le vent), tu peux effectivement faire un message d'erreur pour le joueur sans logé outre mesure a priori.

[Xenos]

J'enregistrerai les erreurs JS dues à une tentative de triche (par exemple, une somme de contrôle ne correspondant pas à la requête JS), car cela peut mettre en exergue les tentatives de piratage, et car il suffit qu'un seul tricheur trouve une faille pour qu'un jeu finisse par terre (Ogame avait explosé principalement à cause des bots qui y pullulaient).

[Sephi-Chan]

Par principe, le mieux est de tout logger (éventuellement dans des logs différents) : ça ne coûte rien et ça peut être très pratique pour identifier des attaques, des oublis, des erreurs récurrentes, etc.

C'est pour ça que je demandais des exemples d'erreurs : on ne traite pas de la même façon une erreur applicative (pas assez d'or pour construire un bâtiment), une erreur technique (la base de données était indisponible) et une attaque (impossible de supprimer un autre compte que le sien, impossible d'acheter telle armure pour -10 pièces d'or).

Le mieux est ensuite de coupler ça à un outil comme Statsd, ou bien FnordMetric ou — si on veut pas s'embêter à installer quelque chose — New Relic. Ça permet de grapher tout ce qu'on veut pour aider à la détection et à la prise de décision.