Certaines fonctions (mais pas toutes) donnent des informations de base sur l'échec, par exemple : quel argument n'est pas celui attendu (s'il y a plusieurs arguments) et ce qui aurait été attendu à la place. Cela devrait être étendu en tant que meilleure pratique pour toutes les fonctions.
Une bonne pratique semble consister en les éléments suivants :
Les autres messages d'erreur ne parlent pas d'un mauvais type, mais d'une mauvaise valeur.
Exemple de bonne pratique pour le moment : " setBackgroundColor : mauvais argument #%d value (la valeur rouge doit être comprise entre 0 et 255, a obtenu %d)"
Suggestion dans le sens ci-dessus : "(Facultatif) L'argument #%d (valeur rouge) a une valeur inattendue ! La valeur attendue doit être comprise entre 0 et 255, a obtenu %d"
En fait, les cas de mauvaise valeur (familièrement, ou du moins par moi, appelés erreurs d' exécution car les arguments fournis sont du bon type mais pas les bonnes valeurs pour produire des résultats valides) commencent déjà à être refaits et s'éloignent de l'exemple cité dans le dernier message. Ils:
setBackgroundColor:
dans l'exemple ci-dessus, car, IIRC selon Vadim l'utilisateur sait quelle est la fonction donc il n'est pas nécessaire de la répéter).lua_error(L)
pour interrompre l'exécution) et peuvent être enveloppés dans du texte supplémentaire à des fins de présentation.En ce qui concerne le rapport de problème initial, je voudrais noter que l'utilisation de l'expression as XXXX expected, got YYYY!
indique un argument requis dans ces messages sur le mauvais type - je viens de compter quelque chose de l'ordre de 180 exemples de cela dans le TLuaInterpreter.cpp
fichier... et pour les arguments as XXXX is optional, got YYYY!
et j'en ai repéré 20 en ce moment. :sourire:
Voici un inventaire des fonctions publiques de TLuaInterpreter
(il existe également d'autres dossiers établissant des fonctions publiques, mais cela semble être le plus grand troupeau)
Source : TLuaInterpreter::initLuaGlobals
La position dans les groupes suivants indique si les messages d'erreur sont (quelque peu) standardisés :
Ces fonctions ont été corrigées maintenant
(à remplir par le bas)
Messages d'erreur à normaliser en effet
Le code source doit être modifié, les messages doivent être améliorés. Ensuite, passez à la section "fixe" ci-dessus et/ou cochez la case
Ces fonctions normalisaient déjà bien les messages
✅ Fonctions internes - inconnues des utilisateurs
✅ Fonctions sans arguments - c'est déjà bien ! ??
La vérification n'est pas encore terminée, mais 65 fonctions ont déjà été trouvées nécessitant des travaux. ??
Mon dernier message ci-dessus est continuellement mis à jour avec le dernier statut pour chacun.
Pour éviter à nouveau une croissance incontrôlée de différents styles de messages d'erreur, la création dudit message doit être centralisée dans une fonction d'aide, qui ne reçoit que les détails énumérés ci-dessus et renvoie la chaîne complète. Par conséquent, les futurs ajustements de la structure des phrases peuvent être apportés _une fois pour toutes_ facilement.
Je ne sais pas si cette refactorisation peut être effectuée avant ou est hors de portée ici.
Le danger s'il n'est pas fait réside dans les messages d'erreur sandardisés aujourd'hui, demain ayant à nouveau une croissance sauvage.
Vérification effectuée. Après avoir regardé ces 400 fonctions publiées depuis TLuaInterpreter pendant quelques heures de plus, nous avons un total de 80 fonctions à corriger. Vous pouvez trouver la liste complète derrière les balises spoiler dans mon commentaire ci-dessus. Des volontaires?
Il y a également eu quelques glissades et erreurs d'inattention qui auraient pu être évitées avec la refactorisation suggérée dans l'OP.
Par exemple, la fonction X se rapporte elle-même en tant que fonction Y (erreur de copier/coller probablement, mais en fait duplication inutile des données)
Bien qu'il y ait encore des travaux en cours en interne pour rationaliser et standardiser la création de texte, ce problème est en grande partie résolu.
Les joueurs ne voient que le message d'erreur de style "mauvais type d'argument" dans setPopup() et plus aucune autre fonction.
Comme expliqué dans https://github.com/Mudlet/Mudlet/pull/4599#issuecomment -756775208, il existe toujours des différences dans le code et la documentation wiki
Je vais marquer cela comme fait. La seule fonction restante (setPopup) est encore discutée dans un numéro séparé n° 4641.
Pendant ce temps, nous avons établi les fonctions d'assistance demandées et donné des erreurs de type et des erreurs de valeur significatives à toutes les fonctions c++.
Vérifié les fonctions Lua, aussi. Tous ne vérifient pas déjà tous leurs arguments, mais s'ils le font, ils donnent des messages d'erreur informatifs.
Commentaire le plus utile
Je vais marquer cela comme fait. La seule fonction restante (setPopup) est encore discutée dans un numéro séparé n° 4641.
Pendant ce temps, nous avons établi les fonctions d'assistance demandées et donné des erreurs de type et des erreurs de valeur significatives à toutes les fonctions c++.
Vérifié les fonctions Lua, aussi. Tous ne vérifient pas déjà tous leurs arguments, mais s'ils le font, ils donnent des messages d'erreur informatifs.