meeting-errors-2020-06-18.md

+**ok hors sujet que reste t'il sur la gestion des erreurs ?**
+
+Ya tous les endroits où on affiche une erreur directement sans la retourner qui utilisent pas un objet, mais je suis pas sûr qu’ils aient besoin. Cela dit ils présentent du coup des problèmes d’échappement dans la plupart des cas à l’heure actuelle.
+
+moi je suis pour la standardisation meme quand cela parait au premier abord non necessaire
+
+En gros le cas dont je parle ici c’est tous les:
+    msg_dialog::display(_('Internal error'), _('Error while adding a lock. Contact the developers!'), ERROR_DIALOG);
+    
+Qui deviendrait:
+    msg_dialog::display(new FusionDirectoryError(htmlescape(_('Error while adding a lock. Contact the developers!'))));
+
+Ou quelque chose comme ça.
+
+**ca me semble bien**
+
+Ok.
+
+Il y a la question des codes d’erreurs. J’avais un peu envie de mettre des codes d’erreur dans les erreurs pour peut-être simplifier la gestion des erreurs quand on utilise le webservice. Mais c’est pas une question simple de répartir les codes d’erreur.
+
+**oui on devrait avoir une discussion sur ca pour voir quel type on a et comment les affecter**
+
+Je suis tombé sur https://softwareengineering.stackexchange.com/questions/98034/how-do-you-assign-error-codes avec un gars qui dit que les codes d’erreurs c’est obsolète.
+
+**effectivement son raisonnement est correct**
+
+Ce que je trouve intéressant dans sa réponse c’est qu’on pourrait effectivement utiliser une chaine d’identification au lieu d’un code d’erreur, genre InsufficientPermissionError, InvalidValueError. Ça serait moins unique qu’un code d’erreur mais on a déjà fichier+ligne si on veut savoir exactement d’où vient l’erreur. Ça nécessiterait à mon avis d’ajouter beaucoup de type d’erreurs différents je sais pas si c’est rentable.
+(Actuellement on a FusionDirectoryError  SimplePluginCheckError  SimplePluginError  class_SimplePluginHookError  SimplePluginLdapError)
+
+**c'est une piste intéressante**
\ No newline at end of file