Je trouve que les messages du journal j'ajouter au cours du développement ne sont généralement l'une des trois choses:
- aide au débogage et le test de nouvelles fonctionnalités inachevées et chemins de code
- Fournir des informations sur le fonctionnement normal du programme telles que l'achèvement de la tâche et les conditions d'erreur communes (par exemple, pas de connexion Internet).
- Fournir des informations détaillées sur les événements inhabituels ou inattendus, y compris les conditions d'erreur qui sont dangereuses ou non spécifiquement traitées, mises à jour logicielles et les données malformés provenant d'une connexion au serveur ou un fichier
Messages dans la catégorie que je retire habituellement quand la fonctionnalité est terminée, les messages dans la catégorie deux, je filtre avec une macro comme celle de la question liée, et les messages dans la catégorie trois, je laisse dans la version.
De toute évidence, les lignes sont floues, mais je pense que cela revient à respecter le journal. Si votre application l'inonde d'informations qui ne sont pas utiles, cela peut rendre difficile la détection d'erreurs provenant d'autres applications et entraînera une (petite) perte de ressources. L'utilisation de fonctions ASL pour consigner des messages dont les priorités sont plus faibles, telles que debug et , qui ne seront pas visibles par la plupart des utilisateurs, est une bonne idée pour les messages qui tombent dans une zone grise.
Les messages de la troisième catégorie doivent être des alertes ou des erreurs présentées, et non des instructions de journal. Combien de vos utilisateurs quittent la console en cours d'exécution au cas où votre application enregistre un échec? –
@Peter, je consigner les erreurs et les avertissements afin que notre gestionnaire d'écrasement (ou la soumission de commentaires des utilisateurs) puisse rechercher ces journaux via ASL et nous les envoyer; l'utilisateur n'a jamais besoin d'ouvrir la console, mais c'est beaucoup plus facile que de lui demander de se souvenir du libellé d'une boîte de dialogue d'erreur! –
@Peter Je suis d'accord. Les messages de journal doivent enregistrer les informations qui n'étaient pas appropriées ou suffisamment spécifiques pour être présentes dans l'interface utilisateur ou pour enregistrer les événements qui ne sont pas suffisamment importants pour en informer l'utilisateur au moment où ils se produisent, mais pourraient être utiles pour trouver la cause d'un problème plus tard. – s4y