Android Log.v (), Log.d (), Log.i (), Log.w (), Log.e () – Quand utiliser chacun d’eux?

Les différentes méthodes de LogCat sont:

 Log.v(); // Verbose Log.d(); // Debug Log.i(); // Info Log.w(); // Warning Log.e(); // Error 

Quelles sont les situations appropriées pour utiliser chaque type de journalisation? Je sais que c’est peut-être juste un peu de sémantique et peut-être que ce n’est pas grave, mais pour le filtrage LogCat dans Android Studio et Eclipse, il serait bon de savoir que j’utilise les méthodes appropriées aux moments appropriés.

Allons dans l’ordre inverse:

  • Log.e : C’est pour les mauvaises choses. Utilisez cette balise dans des endroits comme à l’intérieur d’une instruction catch. Vous savez qu’une erreur est survenue et que vous enregistrez une erreur.

  • Log.w : Utilisez-le lorsque vous pensez que quelque chose se passe de travers . Vous n’êtes peut-être pas complètement en mode erreur, mais vous avez peut-être récupéré d’un comportement inattendu. Fondamentalement, utilisez ceci pour consigner des choses auxquelles vous ne vous attendiez pas, mais ce n’est pas nécessairement une erreur. Un peu comme un “hé, c’est arrivé, et c’est bizarre , nous devrions nous en occuper.”

  • Log.i : Utilisez-le pour publier des informations utiles dans le journal. Par exemple: que vous avez réussi à vous connecter à un serveur. Fondamentalement, utilisez-le pour signaler les succès.

  • Log.d : Utilisez-le à des fins de débogage . Si vous souhaitez imprimer un tas de messages pour pouvoir enregistrer le stream exact de votre programme, utilisez-le. Si vous souhaitez conserver un journal des valeurs des variables, utilisez ceci.

  • Log.v : Utilisez-le quand vous voulez aller complètement fou avec votre enregistrement. Si, pour une raison quelconque, vous avez décidé de vous connecter à une petite partie de votre application, utilisez la balise Log.v.

Et en prime …

  • Log.wtf : Utilisez ceci quand les choses vont absolument, horriblement, la foutaise. Vous connaissez ces blocs de capture où vous attrapez des erreurs que vous ne devriez jamais avoir … ouais, si vous voulez les connecter, utilisez Log.wtf

Les différentes méthodes sont des indications de priorité. Comme vous les avez énumérés, ils vont du moins au plus important. Je pense que la façon dont vous les mappez spécifiquement pour déboguer les journaux dans votre code dépend du composant ou de l’application sur laquelle vous travaillez, ainsi que de la manière dont Android les traite sur différentes versions de génération (eng, userdebug et utilisateur). J’ai beaucoup travaillé sur les démons natifs d’Android, et c’est comme ça que je le fais. Il peut ne pas s’appliquer directement à votre application, mais il peut y avoir des points communs. Si mon explication semble vague, c’est parce que certaines d’entre elles sont plus un art qu’une science. Ma règle de base est d’être aussi efficace que possible, de vous assurer que vous pouvez déboguer raisonnablement votre composant sans détruire les performances du système, et toujours vérifier les erreurs et les enregistrer.

V – Impressions d’état à différents intervalles ou lors d’événements survenant dans mon composant. Également des impressions très détaillées des charges utiles des messages / événements que mon composant reçoit ou envoie.

D – Détails des événements mineurs survenant dans mon composant, ainsi que des charges utiles des messages / événements que mon composant reçoit ou envoie.

I – En-tête de tous les messages / événements que mon composant reçoit ou envoie, ainsi que tous les éléments importants de la charge utile critiques pour le fonctionnement de mon composant.

W – Tout ce qui se passe est inhabituel ou suspect, mais pas nécessairement une erreur.

E – Erreurs, c’est-à-dire des choses qui ne sont pas censées se produire lorsque les choses fonctionnent comme elles le devraient.

La plus grande erreur que je vois commettre est qu’ils abusent de choses comme V, D et I, mais n’utilisent jamais W ou E. Si une erreur est, par définition, non supposée se produire, ou ne devrait se produire que très rarement, alors pas cher pour vous de connecter un message quand il se produit. D’un autre côté, si chaque fois que quelqu’un appuie sur une touche, vous faites un Log.i (), vous abusez de la ressource de journalisation partagée. Bien sûr, faites preuve de bon sens et soyez prudent avec les journaux d’erreur pour les éléments extérieurs à votre contrôle (comme les erreurs de réseau), ou ceux contenus dans des boucles serrées.

Peut-être mauvais

 Log.i("I am here"); 

Bien

 Log.e("I shouldn't be here"); 

En gardant cela à l’esprit, plus votre code devient “prêt pour la production”, plus vous pouvez restreindre le niveau d’enregistrement de base pour votre code (vous avez besoin de V en alpha, D en bêta, I en production ou même W en production ). Vous devez parcourir des cas d’utilisation simples et afficher les journaux pour vous assurer que vous pouvez toujours comprendre ce qui se passe lorsque vous appliquez un filtrage plus ressortingctif. Si vous utilisez le filtre ci-dessous, vous devriez toujours être en mesure de savoir ce que fait votre application, mais peut-être pas obtenir tous les détails.

 logcat -v threadtime MyApp:I *:S 

Le code source fournit des conseils de base:

L’ordre en termes de verbosité, du moins au plus, est ERROR, WARN, INFO, DEBUG, VERBOSE. Verbose ne devrait jamais être compilé dans une application sauf pendant le développement. Les journaux de débogage sont compilés mais supprimés à l’exécution. Les journaux d’erreur, d’avertissement et d’information sont toujours conservés.

Pour plus de détails, la réponse de Kurtis est morte. Je voudrais juste append: Ne pas enregistrer les informations personnelles identifiables ou privées sur INFO ou ci-dessus ( WARN / ERROR ). Sinon, les rapports de bogues ou tout autre élément incluant la journalisation peuvent être pollués.

Je pense que le but de ces différents types de journalisation est que vous souhaitiez que votre application filtre ses propres journaux. Ainsi, Verbose pourrait consigner absolument tout ce qui est important dans votre application, puis le niveau de débogage consignerait un sous-ensemble des journaux détaillés, puis le niveau Info enregistrera un sous-ensemble des journaux de débogage. Lorsque vous arrivez aux journaux d’erreurs, vous souhaitez simplement consigner les erreurs éventuelles. Il existe également un niveau de débogage appelé Fatal lorsque quelque chose frappe vraiment le ventilateur dans votre application.

En général, vous avez raison, c’est fondamentalement arbitraire, et c’est à vous de définir ce qui est considéré comme un journal de débogage par rapport à l’information, par opposition à l’erreur, etc. etc.

Le site Web d’Android Studio a récemment (je pense) fourni quelques conseils sur le type de messages à attendre de différents niveaux de journalisation qui pourraient être utiles avec la réponse de Kurtis:

  • Verbose – Affiche tous les messages du journal (valeur par défaut).
  • Débogage – Affiche les messages de journal de débogage utiles uniquement lors du développement, ainsi que les niveaux de message inférieurs dans cette liste.
  • Info – Affiche les messages de journal attendus pour une utilisation régulière, ainsi que les niveaux de message plus bas dans cette liste.
  • Avertir – Affiche les problèmes possibles qui ne sont pas encore des erreurs, ainsi que les niveaux de message inférieurs dans cette liste.
  • Erreur – Affiche les problèmes qui ont causé des erreurs, ainsi que le niveau de message inférieur dans cette liste.
  • Assert – Affiche les problèmes que le développeur s’attend à ce que cela ne se produise jamais.

Vous pouvez utiliser LOG comme:

 Log.e(Ssortingng, Ssortingng) (error) Log.w(Ssortingng, Ssortingng) (warning) Log.i(Ssortingng, Ssortingng) (information) Log.d(Ssortingng, Ssortingng) (debug) Log.v(Ssortingng, Ssortingng) (verbose) 

exemple de code:

 private static final Ssortingng TAG = "MyActivity"; ... Log.i(TAG, "MyClass.getView() — get item number " + position);