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

Question

Les différents LogCat méthodes 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 d'enregistrement ? Je sais qu'il ne s'agit peut-être que d'une petite question de sémantique et que cela n'a peut-être pas vraiment d'importance, mais pour LogCat filtrant dans Android Studio et Eclipse, il serait agréable de savoir que j'utilise les bonnes méthodes aux bons moments.

Answer 1

Allons-y dans l'ordre inverse :

• Log.e : C'est pour quand de mauvaises choses arrivent. Utilisez cette balise dans des endroits comme l'intérieur d'une déclaration catch. Vous conozca qu'un erreur s'est produite et vous enregistrez donc une erreur.

• Log.w : Utilisez ceci quand vous soupçonnez que quelque chose de louche se passe. Vous n'êtes peut-être pas complètement en mode d'erreur, mais vous avez peut-être récupéré un comportement inattendu. En gros, utilisez ceci pour enregistrer des choses que vous ne vous attendiez pas à voir se produire mais qui ne sont pas nécessairement une erreur. Un peu comme un "hé, ceci est arrivé, et c'est bizarre nous devrions l'examiner."

• Log.i : Utilisez ceci pour poster des informations utiles information au journal. Par exemple : que vous vous êtes connecté avec succès à un serveur. En gros, utilisez-le pour signaler les réussites.

• Log.d : Utilisez ceci pour Débogage objectifs. Si vous voulez imprimer un tas de messages afin d'enregistrer le déroulement exact de votre programme, utilisez ceci. Si vous voulez garder un journal des valeurs des variables, utilisez ceci.

• Log.v : Utilisez cette option lorsque vous voulez devenir complètement fou avec votre enregistrement. Si, pour une raison quelconque, vous avez décidé d'enregistrer chaque petite chose dans une partie particulière de votre application, utilisez la balise Log.v.

Et en prime...

• Log.wtf : Utilisez ceci quand les choses vont absolument, horriblement, mal. Vous savez ces blocs de capture où vous attrapez les erreurs que vous jamais devrait avoir...ouais, si vous voulez les enregistrer, utilisez Log.wtf

Answer 2

Les différentes méthodes sont des indications de priorité. Comme vous les avez énumérées, elles vont du moins important au plus important. Je pense que la façon dont vous les mappez spécifiquement aux journaux de débogage dans votre code dépend du composant ou de l'application sur lequel vous travaillez, ainsi que de la façon dont Android les traite sur les différentes saveurs de construction (eng, userdebug, et user). J'ai fait une bonne quantité de travail dans les démons natifs d'Android, et voici comment je procède. Cela 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 c'est plus un art qu'une science. Ma règle de base est d'être aussi efficace que possible, de m'assurer que vous pouvez raisonnablement déboguer votre composant sans tuer les performances du système, et de toujours vérifier les erreurs et les enregistrer.

V - Impressions de l'état à différents intervalles, ou lors de tout événement survenant que mon composant traite. Il est également possible d'imprimer de manière très détaillée les charges utiles des messages/événements que mon composant reçoit ou envoie.

D - Détails des événements mineurs qui se produisent dans mon composant, ainsi que les charges utiles des messages/événements que mon composant reçoit ou envoie.

I - L'en-tête de tout message/événement que mon composant reçoit ou envoie, ainsi que tout élément important de la charge utile qui est essentiel au fonctionnement de mon composant.

W - Tout ce qui se produit d'inhabituel ou de 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 grosse erreur que je vois commettre est de surutiliser des éléments comme V, D et I, mais de ne jamais utiliser W ou E. Si une erreur n'est, par définition, pas censée se produire, ou ne doit se produire que très rarement, alors il est extrêmement bon marché pour vous d'enregistrer un message lorsqu'elle 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'erreurs pour les choses hors de votre contrôle (comme les erreurs de réseau), ou celles contenues dans des boucles serrées.

Peut-être mauvais

Log.i("I am here");

Bon

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

En gardant tout cela à l'esprit, plus votre code se rapproche de la "production ready", plus vous pouvez restreindre le niveau de journalisation de base de votre code (vous avez besoin de V en alpha, D en bêta, I en production, voire W en production). Vous devriez exécuter quelques cas d'utilisation simples et visualiser les journaux pour vous assurer que vous pouvez toujours comprendre ce qui se passe lorsque vous appliquez un filtrage plus restrictif. Si vous utilisez le filtre ci-dessous, vous devriez toujours être en mesure de savoir ce que votre application fait, mais peut-être pas d'obtenir tous les détails.

logcat -v threadtime MyApp:I *:S

Answer 3

Vous pouvez utiliser des LOG tels que :

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

exemple de code :

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

Answer 4

Le code source fournit quelques conseils de base :

L'ordre en termes de verbosité, du moins au plus, est ERREUR, WARN, INFO, DEBUG, VERBOSE. Verbose ne doit jamais être compilé dans une application, sauf pendant le développement. Les journaux de débogage sont compilés mais supprimés au moment de 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 tout à fait pertinente. J'ajouterais simplement : N'enregistrez pas d'informations personnelles identifiables ou privées à INFO ou plus ( WARN / ERROR ). Sinon, les rapports de bogues ou toute autre chose qui inclut la journalisation peuvent être pollués.

Answer 5

Même si cette question a déjà été traitée, je pense qu'il manque des exemples dans la réponse qui a été donnée.

Je vais donc reprendre ici ce que j'ai écrit dans un billet de blog "Niveaux de logs Android"

Verbose

C'est le niveau le plus bas de journalisation. C'est le niveau le plus bas de la journalisation. Si vous voulez faire des folies avec la journalisation, utilisez ce niveau. Je n'ai jamais compris quand il fallait utiliser Verbose et quand il fallait utiliser Debug. La différence me paraissait très arbitraire. J'ai fini par la comprendre lorsqu'on m'a indiqué le code source d'Android¹ "Verbose ne devrait jamais être compilé dans une application, sauf pendant le développement." Maintenant, c'est clair pour moi, chaque fois que vous développez et que vous voulez ajouter des logs supprimables qui vous aident pendant le développement, il est utile d'avoir le niveau verbose ; cela vous aidera à supprimer tous ces logs avant de passer en production.

Déboguer

C'est à des fins de débogage. C'est le niveau le plus bas qui devrait être en production. Les informations qui s'y trouvent sont destinées à faciliter le développement. La plupart du temps, vous désactiverez ce journal en production afin que moins d'informations soient envoyées et vous ne l'activerez que si vous avez un problème. J'aime enregistrer dans le débogage toutes les informations que l'application envoie/reçoit du serveur (attention à ne pas enregistrer les mots de passe !!!). Ceci est très utile pour comprendre si le bug se situe au niveau du serveur ou de l'application. J'enregistre également les entrées et sorties des fonctions importantes.

Info

Pour les messages d'information qui mettent en évidence la progression de l'application. Par exemple, lorsque l'initialisation de l'application est terminée. Ajouter des informations lorsque l'utilisateur se déplace entre les activités et les fragments. Consigner chaque appel d'API, mais seulement les petites informations comme l'URL, le statut et le temps de réponse.

Avertissement

Lorsqu'il existe une situation potentiellement dangereuse.

Ce journal est, selon mon expérience, un niveau délicat. Quand avez-vous une situation potentiellement dangereuse ? En général ou que c'est OK ou que c'est une erreur. Personnellement, je n'utilise pas beaucoup ce niveau. Les exemples où je l'utilise sont généralement lorsque des choses se produisent plusieurs fois. Par exemple, un utilisateur a un mauvais mot de passe plus de 3 fois. Cela peut être parce qu'il a mal saisi le mot de passe 3 fois, mais aussi parce qu'il y a un problème avec un caractère qui n'est pas accepté par notre système. Il en va de même pour les problèmes de connexion au réseau.

Erreur

Événements d'erreur. L'application peut continuer à fonctionner après l'erreur. Cela peut être par exemple lorsque je reçois un pointeur nul alors que je ne suis pas censé en recevoir un. Une erreur s'est produite lors de l'analyse de la réponse du serveur. J'ai reçu une erreur du serveur.

WTF (What a Terrible Failure - Quel terrible échec)

Fatal correspond à des erreurs graves qui conduisent l'application à se fermer. Dans Android, le fatal est en réalité le niveau d'erreur, la différence est qu'il ajoute également la pile complète.