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

Les différentes LogCatmé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 de journalisation? Je sais que c'est peut-être juste un peu de sémantique et peut-être que cela n'a pas vraiment d'importance, mais pour le LogCatfiltrage dans Android Studio et Eclipse, ce serait bien de savoir que j'utilise les bonnes méthodes aux moments appropriés.

Allons dans l'ordre inverse:

• Log.e : C'est pour quand de mauvaises choses se produisent. Utilisez cette balise à des endroits comme dans une déclaration catch. Vous savez qu'une erreur s'est produite et vous enregistrez donc une erreur.

• Log.w : utilisez-le lorsque 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é d'un comportement inattendu. Fondamentalement, utilisez-le pour enregistrer des choses que 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 y réfléchir."

• Log.i : utilisez-le pour publier des informations utilesdans 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 afin de pouvoir enregistrer le flux exact de votre programme, utilisez ceci. Si vous souhaitez conserver un journal des valeurs des variables, utilisez-le.

• Log.v : utilisez ceci lorsque vous voulez devenir complètement fou avec votre journalisation. 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 bonus ...

• Log.wtf : utilisez-le lorsque les choses se passent de manière absolument horrible, sacrément mauvaise Vous connaissez ces blocs catch où vous attrapez des erreurs que vous ne devriez jamais obtenir ... ouais, si vous voulez les enregistrer, 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 façon dont Android les traite selon différentes versions de construction (eng, userdebug et user). J'ai fait pas mal de travail dans les démons natifs d'Android, et c'est ainsi que je le fais. Il peut ne pas s'appliquer directement à votre application, mais il peut y avoir un terrain d'entente. Si mon explication semble vague, c'est parce que certaines choses relèvent davantage d'un art que d'une science. Ma règle de base est d'être aussi efficace que possible, de vous assurer que vous pouvez raisonnablement déboguer votre composant sans tuer les performances du système, et toujours vérifier les erreurs et les enregistrer.

V - Impressions d'état à différents intervalles, ou lors de tout événement survenu que mon composant traite. É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 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 tous les messages / événements que mon composant reçoit ou envoie, ainsi que tous les éléments importants de la charge utile qui sont essentiels au fonctionnement de mon composant.

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

E - Erreurs, ce qui signifie 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 est que les gens abusent de choses comme V, D et I, mais n'utilisent jamais W ou E. Si une erreur n'est, par définition, pas censée se produire, ou ne devrait se produire que très rarement, alors c'est extrêmement pas cher pour vous d'enregistrer un message quand il se produit. D'un autre côté, si chaque fois que quelqu'un appuie sur une touche, vous effectuez un Log.i (), vous abusez de la ressource de journalisation partagée. Bien sûr, utilisez votre 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");

Bien

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

Avec tout cela à l'esprit, plus votre code se rapproche de la "production prête", plus vous pouvez restreindre le niveau de journalisation de base pour votre code (vous avez besoin de V en alpha, D en bêta, I en production, ou peut-être même W en production ). Vous devez parcourir quelques cas d'utilisation simples et afficher les journaux pour vous assurer que vous pouvez toujours comprendre la plupart du temps ce qui se passe lorsque vous appliquez un filtrage plus restrictif. Si vous exécutez avec le filtre ci-dessous, vous devriez toujours être en mesure de dire ce que fait votre application, mais peut-être pas obtenir tous les détails.

logcat -v threadtime MyApp:I *:S

Le code source fournit quelques conseils de base:

L'ordre en termes de verbosité, du moins au plus, est ERREUR, AVERTISSEMENT, INFO, DÉBOGAGE, 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 lors de l'exécution. Les journaux d'erreurs, d'avertissements et d'informations sont toujours conservés.

Pour plus de détails, la réponse de Kurtis est morte. J'ajouterais simplement: N'enregistrez aucune information personnellement identifiable ou privée à INFOou au -dessus ( WARN/ ERROR). Sinon, les rapports de bogues ou tout autre élément incluant la journalisation peuvent être pollués.

Vous pouvez utiliser LOG comme:

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);

Je pense que l'intérêt de ces différents types de journalisation est que si vous voulez que votre application filtre automatiquement ses propres journaux. Verbose pourrait donc 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 consignerait un sous-ensemble des journaux de débogage. Lorsque vous arrivez aux journaux d'erreurs, vous souhaitez simplement enregistrer toutes sortes d'erreurs qui peuvent s'être produites. 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 essentiellement arbitraire, et c'est à vous de définir ce qui est considéré comme un journal de débogage versus informationnel, versus et erreur, etc. etc.

Même si cette question a déjà été répondue, j'estime qu'il manque des exemples dans la réponse à laquelle on a répondu.

Je vais donc apporter ici ce que j'ai écrit dans un article de blog "Android Log Levels"

Verbeux

Est le niveau de journalisation le plus bas. Si vous voulez devenir fou avec la journalisation, vous allez avec ce niveau. Je n'ai jamais compris quand utiliser Verbose et quand utiliser Debug. La différence m'a semblé très arbitraire. Je l'ai finalement compris une fois que j'ai été pointé vers le code source d'Android¹ "Verbose ne devrait jamais être compilé dans une application sauf pendant le développement." Maintenant, il est clair pour moi que chaque fois que vous développez et que vous souhaitez ajouter des journaux supprimables qui vous aident pendant le développement, il est utile d'avoir le niveau détaillé, cela vous aidera à supprimer tous ces journaux avant de passer en production.

Déboguer

Est à des fins de débogage. Il s'agit du niveau le plus bas qui devrait être en production. Les informations qui se trouvent ici sont destinées à vous aider pendant le développement. La plupart du temps, vous désactivez ce journal dans la production afin que moins d'informations soient envoyées et n'activez ce journal qu'en cas de problème. J'aime me connecter déboguer 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 bogue se trouve sur le serveur ou l'application. Je fais également des journaux d'entrée et de sortie de fonctions importantes.

Info

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

avertissement

En cas de 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. Des exemples de cas où je l'utilise sont généralement lorsque des choses se produisent plusieurs fois. Par exemple, un utilisateur a un mot de passe incorrect plus de 3 fois. Cela peut être dû au fait qu'il a mal saisi le mot de passe 3 fois, cela peut également être dû à un problème avec un caractère qui n'est pas accepté dans notre système. Il en va de même avec les problèmes de connexion réseau.

Erreur

Événements d'erreur. L'application peut continuer à fonctionner après l'erreur. Cela peut être par exemple lorsque j'obtiens un pointeur nul où je ne suis pas censé en obtenir un. Une erreur s'est produite lors de l'analyse de la réponse du serveur. Vous avez une erreur du serveur.

WTF (quel terrible échec)

Fatal est pour les événements d'erreur graves qui conduiront l'application à se fermer. Dans Android, le fatal est en réalité le niveau d'erreur, la différence est qu'il ajoute également le fullstack.

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

• Verbose - Affiche tous les messages du journal (par défaut).
• Débogage - Affiche les messages du journal de débogage qui sont utiles uniquement pendant le 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 - Afficher les problèmes qui ont causé des erreurs, ainsi que le niveau de message inférieur dans cette liste.
• Assert - Afficher les problèmes que le développeur attend ne devraient jamais se produire.