Discussion :

[ymoreau]

Bonjour,
Je voudrais avoir votre avis sur les messages d'erreur, j'ai déjà une classe qui s'occupe d'écrire dans un log, mais il me faut aussi prévenir l'utilisateur lorsque quelque chose ne fonctionne pas (au moins pour certains cas).

Par exemple, j'ai un menu pour changer de langue, si il y a une erreur lors du changement (un fichier de traduction introuvable), je pensais afficher un QMessageBox::warning prévenant l'utilisateur que la langue n'a pas pu être changée. A votre avis est-il utile de donner des détails sur l'erreur ? sachant qu'elle est déjà écrite dans le log.

Si oui, je ne vois que les exceptions pour faire passer le message textuel détaillant l'erreur. Mais cela complique un peu la fonction comparé à un simple retour booléen. Est-ce que vous mettez en commun le message de log et celui présenté à l'utilisateur ? J'aurais tendance à penser que le log sera plutôt lu par des personnes qui s'y connaissent, alors que le message graphique s'adresse à tout type de personne.

Quelle est selon vous la meilleure méthode pour gérer ce genre de messages, et où placez vous la frontière entre message utile pour l'utilisateur et message plutôt technique (pour le débogage) ? merci d'avance de vos avis !

[Architekth]

Personnellement, je pense que le log est effectivement plus orienté pour les personnes qui s'y connaissent, et entre autre les développeurs de l'application. ça aide à déboguer. Les messages graphiques (sous forme de QMessageBox) eux sont plus orienté pour l'utilisateur, sa permet de l'aider à comprendre l'erreur qu'il a commis. Moi j'utilise les messages graphiques lorsque l'utilisateur a réalisé une opération non conforme pour qu'il comprend d'où vient le problème.

[ymoreau]

Oui je suis d'accord. A vrai dire ma question se pose plutôt pour les cas où l'utilisateur n'a pas fait d'erreur justement, un fichier qui manque ou une opération qui se passe mal, dans ces cas là l'utilisateur ne comprendra probablement pas pourquoi ça ne marche pas. Et ma question est plutôt à quel point l'informer de la situation, lui dire "désolé ça marche pas" point barre, ou donner plus de détails.

Et puis surtout je voudrais connaître la manière "technique" dont vous gérez ces messages, entre log, message box etc.

[_skip]

Perso j'affiche dans une boîte de dialogue un message comme quoi l'opération a échoué (internationalisé).
Ensuite retour à la ligne, je met le message d'erreur système (tel que récupéré de l'API, tant pis s'il est en anglais).

Des erreurs comme tu cites sont suffisamment exceptionnelles pour que tu t'autorises à les présenter de façon un peu brute. Si tu donnes aucun complément d'information sauf un "désolé ça marche pas", quand tu seras au téléphone avec la personne, tout ce qu'elle pourra te dire c'est "ça marche pas".

En revanche les erreurs anticipées d'utilisation, champ mal rempli, saisie incomplète, méritent des jolis messages internationalisés.

Chose à ne pas faire : Internationaliser les messages d'erreur système. C'est fastidieux et c'est de la perte de temps. Des manipulations sur le système de fichier peuvent lever 7-8 erreurs différentes, inutile à mon sens de se casser à inventer une belle phrase pour chacune d'entre elles.

[ymoreau]

Merci de vos réponses. Du coup j'ai écrit une macro de ce type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
#define THROW_AND_WARN(exceptionClass, message) do {\
WARN(message);\
throw exceptionClass(message); } while(false)

Où le message est le message technique (donc non internationalisé). Le but de la macro est de ne pas réécrire deux fois en dur le message dans le code.

Si quelqu'un a une meilleure méthode, je suis preneur :)

[_skip]

C'est quoi WARN?

[ymoreau]

Une autre macro à moi qui appelle une fonction de log en donnant le nom de fichier et le numéro de ligne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#define WARN(msg) Logger::ref().log(msg, __FILE__, __LINE__, Logger::Error)

Une fonction aurait été plus propre qu'une macro, mais pour pouvoir afficher le fichier et le numéro de ligne c'est impossible.

[_skip]

En gros tu logges et ensuite tu lances une exception?
Franchement je pense que c'est plutôt le code qui réceptionne l'exception qui devrait logger, tu crois pas?

Sinon tu vas avoir des appels au Logger à 25 millions de places dans ton code et à toutes les profondeurs.

[ymoreau]

J'y ai pensé mais si c'est le code qui réceptionne l'exception qui écrit le log, le fichier et la ligne n'auront pas de sens car trop haut niveau par rapport à l'erreur. En quoi ça serait un problème qu'il y ait des appels au log à tous les niveaux ? C'est uniquement en cas d'erreur donc à priori jamais.

[_skip]

C'est ton exception qui devrait contenir ces informations.

Tiens regarde comment ils ont fait du côté de boost :
http://www.boost.org/doc/libs/1_41_0...EXCEPTION.html

Pour ce qui est des appels au log à tous les niveaux, je ne sais pas quelle est la philosophie dominante en C++ mais en java ou en .Net avec lesquels j'ai pas mal d'expérience, on essaie le plus possible de séparer les responsabilités.
En ce sens, une classe métier ne devrait en principe pas s'occuper de logger, en théorie elle n'est là que pour fournir une API de haut niveau servant à exécuter une fonctionnalité et laisser le code consommateur décider ce qu'il est pertinent de faire en cas d'erreur (réessayer? logger? présenter l'erreur?).

Ainsi ce que tu écris est beaucoup plus réutilisable.

[ymoreau]

Je n'avais pas vu les choses sous cet angle, c'est vrai que ça me parait mieux. Merci pour ces conseils !