Cela a été inspiré par la recherche d'un message d'erreur non documenté pour l'Open-Command où nous avons investi beaucoup de temps pour rechercher la cause de l'erreur qui aurait pu être évitée si le message d'erreur était significatif et documenté, par exemple dans l'index de script.
En fait, nous avons obtenu l'erreur "Impossible d'ouvrir la table à la ligne " plusieurs fois mais non reproductible lors de l'ouverture de fichiers CSV à l'aide d'Open-Command. Après une longue recherche, nous avons constaté que les actions de copie de fichiers volumineux via le réseau prennent parfois beaucoup de temps et, en cas de réseau instable, sont abandonnées après un certain temps. timeout. Cela signifie qu'une partie du contenu du fichier peut être transférée mais pas l'autre partie et sera remplie de valeurs Null.
J'aimerais voir une amélioration de ces messages d'erreur insignifiants en :
- les transférer vers des messages significatifs "Impossible d'ouvrir la table à la ligne " => par exemple "Le fichier est corrompu et ne peut pas être lu à la ligne "
- documentez-le au moins dans l'index des scripts en donnant des exemples dans le code
- rendre le texte de la langue du message d'erreur indépendant en anglais
- renvoyer des numéros d'erreur indépendants de la langue, comme dans le monde Windows, par exemple
- une fonction exception_code() qui renvoie un tableau d'un numéro d'erreur et d'une erreur indépendante de la langue sous forme de chaîne { 93, "File not found"} ou similaire. Ce serait formidable d'interroger le code d'erreur et de présenter un message personnalisé à l'utilisateur.
Cette idée est importante pour réduire les temps de recherche inutiles des messages d’erreur et améliorer la prévention et la prise en charge des erreurs.
@martindemel
