Normalisation json

[terry3772]

Bonjour Boris,

-----Suggestion d'évolution : Dans ton module linky / index.js, je suggère de normaliser les return en remplaçant les parties throw par des retours au format json.

-----Usage : Utiliser ton module comme une API dont le format retourné serait standard. Dans un programme appelant (par exemple boucle infinie à intervalle régulier, qui récupère la conso de la veille), ça ne permettrait de traiter le retour de manière simple en n'ayant qu'à tester "return.status".

-----EXEMPLES : getDailyConsumption( 2022-05-19 , 2022-05-20 ) { status: 0, message: 'success', unit: 'Wh', data: [ { date: '2022-05-19', value: 6357 } ] }

getDailyConsumption( 2022-05-19 , 2022-05-21 )
{
status: 400,
message: 'Invalid request: The end date parameter must be earlier than the current date.', unit: 'none',
data: []
}

etc.

-----Exemple de modification : //throw new Error("Error from the Enedis API\nCode: " + err.response.status + "\nResponse: " + JSON.stringify(err.response.data, null, 4)); return { status : err.response.status, message : "Error from the Enedis API: " + JSON.stringify(err.response.data, null, 4), unit: "none", data: [], };

[bokub]

Salut Thierry,

Non, mon module ne va pas retourner un objet alors qu'une erreur s'est produite, ça n'a aucun sens.

En revanche, tu as raison sur le fait qu'il pourrait y avoir plus détails dans les erreurs.

On pourrait par exemple throw des erreurs custom qui ont un champ status et un champ data en plus du message existant.

Mon repo est ouvert aux pull request, je t'invite à en ouvrir une si tu le souhaites

P.S Tu peux utiliser la syntaxe markdown pour formater tes blocs de code et tes titres parce que là c'est difficilement lisible. Par exemple :

Exemple titre

Exemple de code

[terry3772]

Bonjour Boris,

Personnellement, ça ne me choque pas d'avoir une vision générique et considérer qu'une erreur est une donnée comme une autre avec champs status valorisé et un champs data vide. Mais je comprends et respecte ta vision puriste.

Voila en fait, pourquoi je défends cette vision. Dans le cas de l'appel de ton module dans une boucle de programmation, il y a selon moi 2 types d'erreur : -les fatales, qui méritent la sortie de la boucle [cas du refresh token qui ne fonctionne pas] -les mineures souvent temporaires, qui méritent de rester dans la boucle, et donc de relancer la requête (après la temporisation) [cas connu ;-) de récupération trop tôt des données de la veille]

Mais on peut évidemment procéder autrement et ta solution "throw des erreurs custom qui ont un champ status et un champ data en plus du message existant" peut constituer un bon compromis 👍 Peux-tu juste me donner un exemple de syntaxe; je soumettrai une pull request après quelques jours de vacances...

Merci de l'échange et de la qualité de tes réponses.

[bokub]

Effectivement, il y a 2 façons de voir les choses, tu as tout à fait raison.

Un bon parallèle serait la librairie axios par rapport l'API fetch de JavaScript, qui servent tous les deux à faire des requêtes HTTP.

• fetch a pris le parti de n'envoyer une erreur que si la requête ne peut pas être faite. Si elle reçoit un code 500, elle ne throw rien du tout
• axios, quant à lui, throw une erreur personnalisée du moment que le code de retour n'est pas 2XX.

Résultat: Beaucoup de développeurs galèrent avec fetch car il faut gérer plusieurs formats de réponse dans le cas nominal, et la gestion des erreurs est un vrai casse tête.

Je suis plutôt partisan de l'approche d'axios: si il y a une erreur, quelle qu'elle soit, je la catégorise comme une erreur.

Si toi, en tant qu'utilisateur de ma librairie, a envie de faire un traitement personnalisé en fonction des erreurs, libre à toi de catch cette erreur et de choisir quoi faire avec, mais ce n'est pas la responsabilité de la lib de déterminer si une erreur est "fatale" ou "mineure", cela dépend complètement de ton cas d'usage.

Par exemple, mon outil linky en ligne de commande n'a pas de notion de "fatale" ou "mineure", il s'arrête en cas d'erreur et affiche le problème, quelle que soit l'erreur Le traitement serait différent si c'était un serveur domotique par exemple.

[bokub]

Si tu veux créer une Erreur custom, tu peux suivre ce wiki par exemple, ou bien chercher sur Google quelque chose comme "extend Error typescript".

Tu pourras ensuite throw new MaCustomError avec des détails en plus

Bonne journée et merci à toi aussi pour l'échange !