Android Log v Log d Log i Log w Log e - When to use each one

Question

The different LogCat methods are   Log v       Verbose Log d       Debug Log i       Info Log w       Warning Log e       Error   What are the appropriate situations to use each type of Logging  I know that perhaps it s just a little bit of semantics and perhaps it doesn t really matter  but for LogCat filtering in Android Studio and Eclipse  it would be nice to know I am using the proper methods at the appropriate times

User · Accepted Answer

Let s go in reverse order    Log e  This is for when bad stuff happens  Use this tag in places like inside a catch statement  You know that an error has occurred and therefore you re logging an error  Log w  Use this when you suspect something shady is going on  You may not be completely in full on error mode  but maybe you recovered from some unexpected behavior  Basically  use this to log stuff you didn t expect to happen but isn t necessarily an error  Kind of like a  hey  this happened  and it s weird  we should look into it   Log i  Use this to post useful information to the log  For example  that you have successfully connected to a server  Basically use it to report successes  Log d  Use this for debugging purposes  If you want to print out a bunch of messages so you can log the exact flow of your program  use this  If you want to keep a log of variable values  use this  Log v  Use this when you want to go absolutely nuts with your logging  If for some reason you ve decided to log every little thing in a particular part of your app  use the Log v tag    And as a bonus      Log wtf  Use this when stuff goes absolutely  horribly  holy-crap wrong  You know those catch blocks where you re catching errors that you never should get   yeah  if you wanna log them use Log wtf

User · Answer

You can use LOG such as    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    example code    private static final String TAG    MyActivity       Log i TAG   MyClass getView       get item number     position

User · Answer

Even though that this question was already answered I feel that there are missing examples in the answer that was answered   Therefore I ll bring here what I wrote in a blog post  Android Log Levels    Verbose  Is the lowest level of logging  If you want to go nuts with logging then you go with this level  I never understood when to use Verbose and when to use Debug  The difference sounded to me very arbitrary  I finally understood it once I was pointed to the source code of Android      Verbose should never be compiled into an application except during development     Now it is clear to me  whenever you are developing and want to add deletable logs that help you during the development it is useful to have the verbose level this will help you delete all these logs before you go into production   Debug  Is for debugging purposes  This is the lowest level that should be in production  Information that is here is to help during development  Most times you   ll disable this log in production so that less information will be sent and only enable this log if you have a problem  I like to log in debug all the information that the app sends receives from the server  take care not to log passwords      This is very helpful to understand if the bug lies in the server or the app  I also make logs of entering and exiting of important functions   Info  For informational messages that highlight the progress of the application  For example  when initialising of the app is finished  Add info when the user moves between activities and fragments  Log each API call but just little information like the URL   status and the response time   Warning  When there is a potentially harmful situation   This log is in my experience a tricky level  When do you have a potential harmful situation  In general or that it is OK or that it is an error  I personally don   t use this level much  Examples of when I use it are usually when stuff happens several times  For example  a user has a wrong password more than 3 times  This could be because he entered the password wrongly 3 times  it could also be because there is a problem with a character that isn   t being accepted in our system  Same goes with network connection problems   Error  Error events  The application can still continue to run after the error  This can be for example when I get a null pointer where I   m not supposed to get one  There was an error parsing the response of the server  Got an error from the server   WTF  What a Terrible Failure   Fatal is for severe error events that will lead the application to exit  In Android the fatal is in reality the Error level  the difference is that it also adds the fullstack

User · Answer

The different methods are indications of priority   As you ve listed them  they re going from least to most important   I think how you specifically map them to debug logs in your code depends on the component or app you re working on  as well as how Android treats them on different build flavors  eng  userdebug  and user    I have done a fair amount of work in the native daemons in Android  and this is how I do it   It may not apply directly to your app  but there may be some common ground   If my explanation sounds vague  it s because some of this is more of an art than a science   My basic rule is to be as efficient as possible  ensure you can reasonably debug your component without killing the performance of the system  and always check for errors and log them   V - Printouts of state at different intervals  or upon any events occurring which my component processes   Also possibly very detailed printouts of the payloads of messages events that my component receives or sends   D - Details of minor events that occur within my component  as well as payloads of messages events that my component receives or sends   I - The header of any messages events that my component receives or sends  as well as any important pieces of the payload which are critical to my component s operation   W - Anything that happens that is unusual or suspicious  but not necessarily an error   E - Errors  meaning things that aren t supposed to happen when things are working as they should   The biggest mistake I see people make is that they overuse things like V  D  and I  but never use W or E   If an error is  by definition  not supposed to happen  or should only happen very rarely  then it s extremely cheap for you to log a message when it occurs   On the other hand  if every time somebody presses a key you do a Log i    you re abusing the shared logging resource   Of course  use common sense and be careful with error logs for things outside of your control  like network errors   or those contained in tight loops   Maybe Bad  Log i  I am here      Good  Log e  I shouldn t be here      With all this in mind  the closer your code gets to  production ready   the more you can restrict the base logging level for your code  you need V in alpha  D in beta  I in production  or possibly even W in production    You should run through some simple use cases and view the logs to ensure that you can still mostly understand what s happening as you apply more restrictive filtering   If you run with the filter below  you should still be able to tell what your app is doing  but maybe not get all the details   logcat -v threadtime MyApp I   S

User · Answer

The Android Studio website has recently  I think  provided some advice what kind of messages to expect from different log levels that may be useful along with Kurtis  answer     Verbose - Show all log messages  the default     Debug - Show debug log messages that are useful during development only  as well as the message levels lower in this list  Info - Show expected log messages for regular usage  as well as the message levels lower in this list  Warn - Show possible issues that are not yet errors  as well as the message levels lower in this list  Error - Show issues that have caused errors  as well as the message level lower in this list  Assert - Show issues that the developer expects should never happen

User · Answer

The source code provides some basic guidance      The order in terms of verbosity  from least to most is ERROR  WARN  INFO  DEBUG  VERBOSE   Verbose should never be compiled into an application except during development   Debug logs are compiled in but stripped at runtime   Error  warning and info logs are always kept    For more detail  Kurtis  answer is dead on   I would just add  Don t log any personally identifiable or private information at INFO or above  WARN ERROR    Otherwise  bug reports or anything else that includes logging may be polluted

User · Answer

I think the point of those different types of logging is if you want your app to basically self filter its own logs  So Verbose could be to log absolutely everything of importance in your app  then the debug level would log a subset of the verbose logs  and then Info level will log a subset of the debug logs  When you get down to the Error logs  then you just want to log any sort of errors that may have occured  There is also a debug level called Fatal for when something really hits the fan in your app   In general  you re right  it s basically arbitrary  and it s up to you to define what is considered a debug log versus informational  versus and error  etc  etc

[android] Android Log.v(), Log.d(), Log.i(), Log.w(), Log.e() - When to use each one?

Examples related to android

Examples related to logcat