Android Log.v (), Log.d (), Log.i (), Log.w (), Log.e () - Quand les utiliser?
Les différentes méthodes 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 un peu de sémantique et que cela n'a pas vraiment d'importance, mais pour le filtrage LogCat dans Android Studio et Eclipse, il serait intéressant de savoir que j'utilise les méthodes appropriées aux moments appropriés.
Allons dans l'ordre inverse:
Log.e : C'est pour que de mauvaises choses arrivent. Utilisez cette balise à des endroits comme dans une instruction catch. Vous savez qu'une erreur s'est produite et vous enregistrez une erreur.
Log.w : Utilisez ceci lorsque vous suspectez quelque chose de louche. Vous pouvez ne pas être complètement en mode erreur, mais peut-être avez-vous récupéré un comportement inattendu. En gros, utilisez ceci pour enregistrer des choses que vous ne pensiez pas arriver mais qui ne sont pas nécessairement une erreur. Un peu comme un "hé, c'est arrivé, et c'est bizarre, nous devrions examiner cela."
Log.i : Utilisez cette option pour publier des informations utiles dans le journal. Par exemple: vous vous êtes connecté avec succès à un serveur. Fondamentalement, utilisez-le pour signaler les succès.
Log.d : Utilisez ceci à des fins de débogage. Si vous souhaitez imprimer un tas de messages afin que vous puissiez enregistrer le flux exact de votre programme, utilisez ceci. Si vous souhaitez conserver un journal des valeurs de variables, utilisez ceci.
Log.v : Utilisez-le lorsque vous voulez vous rendre complètement fou avec votre journalisation. Si, pour une raison quelconque, vous avez décidé de consigner chaque petite chose dans une partie particulière de votre application, utilisez la balise Log.v.
Et en bonus ...
- Log.wtf : Utilisez ceci lorsque tout va mal, absolument, horriblement mal. Vous connaissez les blocages où vous rencontrez des erreurs que vous jamais devriez obtenir ... ouais, si vous voulez les consigner, utilisez Log.wtf
Les différentes méthodes sont des indications de priorité. Comme vous les avez énumérés, ils vont du moins important au plus important. Je pense que la façon dont vous les mappez de manière spécifique aux journaux de débogage 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 sur différentes versions (eng, userdebug et user). J'ai effectué pas mal de travail dans les démons natifs d'Android, et voici comment je le fais. Cela 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 cela est davantage un art qu'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 nuire aux performances du système, et de toujours rechercher les erreurs et de les consigner.
V - Les impressions d'état à des intervalles différents, ou lors de tout événement survenant par mon composant. Également éventuellement des impressions très détaillées des données utiles des messages/événements que mon composant reçoit ou envoie.
D - Détails des événements mineurs survenus dans mon composant, ainsi que des données 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 de tous les éléments importants de la charge utile essentiels au fonctionnement de mon composant.
W - Tout ce qui se passe est inhabituel ou suspect, mais pas nécessairement une erreur.
E - Erreurs, signifiant 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 utilisent trop de choses comme V, D et moi, 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, elle est extrêmement pas cher pour vous connecter un message quand il se produit. D'un autre côté, si chaque fois que vous appuyez sur une touche, vous effectuez un Log.i (), vous abusez de la ressource de journalisation partagée. Bien sûr, faites preuve de bon sens et faites attention aux journaux d'erreurs pour les éléments hors de 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 se rapproche de la «production prête», plus vous pouvez limiter le niveau d’enregistrement de base de votre code (vous avez besoin de V en alpha, D en bêta, I en production, voire même en production). ). Vous devez parcourir quelques cas d'utilisation simples et consulter les journaux pour vous assurer que vous pouvez toujours comprendre l'essentiel de l'application lorsque vous appliquez un filtrage plus restrictif. Si vous utilisez le filtre ci-dessous, vous devriez toujours pouvoir 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 indications de base:
L'ordre en termes de verbosité, du moins au plus grand, 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 dans mais supprimés au moment 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 sans appel. Je voudrais simplement ajouter: Ne consignez aucune information personnellement identifiable ou privée à INFO ou plus (WARN/ERROR). Sinon, les rapports de bogues ou tout ce qui inclut la journalisation peuvent être pollués.
Je pense que l’intérêt de ces différents types d’enregistrement est que vous voulez que votre application filtre elle-même ses propres journaux. Donc, Verbose pourrait consigner absolument tout ce qui est important dans votre application, puis le niveau de débogage consignera un sous-ensemble des journaux détaillés, puis le niveau Info enregistrera un sous-ensemble des journaux de débogage. Lorsque vous abordez les journaux d’erreurs, vous souhaitez simplement enregistrer toute sorte d’erreurs éventuelles. Il existe également un niveau de débogage appelé Fatal lorsque quelque chose frappe vraiment le fan de 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 opposition à informationnel, par opposition à erreur, etc.
Le site Web de Android Studio a récemment (je pense) fourni des conseils sur le type de messages à attendre de différents niveaux de journalisation pouvant être utiles avec la réponse de Kurtis:
- Verbose - Affiche tous les messages du journal (par défaut).
- Debug - Affiche les messages du journal de débogage qui ne sont utiles que pendant le développement, ainsi que les niveaux de message plus bas dans cette liste.
- Info - Affiche les messages de journal attendus pour une utilisation normale, ainsi que les niveaux de message plus bas dans cette liste.
- Warn - Affiche les problèmes possibles qui ne sont pas encore des erreurs, ainsi que les niveaux de message plus bas dans cette liste.
- Error - Affiche les problèmes qui ont causé des erreurs, ainsi que le niveau de message plus bas dans cette liste.
- Assert - Affiche les problèmes qui, selon le développeur, ne devraient jamais se produire.
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);
Même si cette question a déjà été répondue, j’ai le sentiment qu’il manque des exemples dans la réponse.
Je vais donc apporter ici ce que j'ai écrit dans un article de blog "Android Log Levels"
Verbose
Est le plus bas niveau de journalisation. Si vous voulez devenir fou avec la journalisation, alors vous allez avec ce niveau. Je n'ai jamais compris quand utiliser Verbose et quand utiliser Debug. La différence me semblait très arbitraire. J'ai finalement compris une fois que le code source d'Android m'avait été pointé. «Verbose ne devrait jamais être compilé dans une application, sauf pendant le développement. développement, il est utile d’avoir le niveau détaillé pour vous aider à supprimer tous ces journaux avant de passer en production.
Debug
Est à des fins de débogage. C'est le niveau le plus bas qui devrait être en production. L'information qui est ici est d'aider au cours du développement. La plupart du temps, vous désactiverez ce journal en production afin d’envoyer moins d’informations et ne l’activez que si vous rencontrez un problème. J'aime me connecter pour déboguer toutes les informations que l'application envoie/reçoit du serveur (veillez à ne pas enregistrer les mots de passe !!!). Ceci est très utile pour comprendre si le bogue réside dans le serveur ou l'application. Je fais également des journaux des entrées et des sorties des fonctions importantes.
Info
Pour les messages d’information qui mettent en évidence les progrès de l’application. Par exemple, lorsque l'initialisation de l'application est terminée. Ajoutez des informations lorsque l'utilisateur passe d'une activité à une autre. Consignez chaque appel d'API mais peu d'informations, telles que l'URL, le statut et le temps de réponse.
Attention
Quand il y a une situation potentiellement dangereuse.
Ce journal est à mon avis 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 quand je l'utilise sont généralement lorsque des choses se passent plusieurs fois. Par exemple, un utilisateur a un mot de passe incorrect plus de 3 fois. C’est peut-être parce qu’il a entré le mot de passe à tort 3 fois, mais aussi parce qu’il ya un problème avec un personnage qui n’est pas accepté dans notre système. Même chose avec les problèmes de connexion réseau.
Erreur
Événements d'erreur. L'application peut toujours continuer à s'exécuter après l'erreur. Cela peut être le cas, par exemple, lorsque je reçois un pointeur nul alors que 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 destiné aux événements d'erreur grave qui entraîneront la fermeture de l'application. Dans Android, l'élément fatal est en réalité le niveau d'erreur, la différence est qu'il ajoute également le fullstack.