Log.v(), Log.d(), Log.i(), Log.w() and Log.e() - When to use each one?



I found a wonderful explanation of these on Stackoverflow and I stole them from Kurtis Nusbaum so you won't have to.

You're welcome!

So... you come to me and ask:

When and which one to use?


Let me (that is... him) tell you what I stole:

  • Log.e: This is for when bad stuff happens. Use this tag in places like inside a catch statment. 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...yea, if you wanna log them use Log.wtf

Comments

Post a Comment

Popular posts from this blog

Userful applications

Scoop What does Scoop do? Scoop installs programs from the command line with a minimal amount of friction. It tries to eliminate things like: Permission popup windows GUI wizard-style installers Path pollution from installing lots of programs Unexpected side-effects from installing and uninstalling programs The need to find and install dependencies The need to perform extra setup steps to get a working program Scoop is very scriptable, so you can run repeatable setups to get your environment just the way you like, e.g.: scoop install sudo sudo scoop install 7zip git openssh -- global scoop install aria2 curl grep sed less touch scoop install python ruby go perl If you've built software that you'd like others to use, Scoop is an alternative to building an installer (e.g. MSI or InnoSetup)—you just need to zip your program and provide a JSON manifest that describes how to install it. Install Scoop Run this command from your PowerShell to install scoop to i
Read more

Environment variables for Android development

ANDROID_HOME Deprecated (in Android Studio), use ANDROID_SDK_ROOT instead. ANDROID_SDK_ROOT Installation directory of Android SDK package. Example: C:\AndroidSDK or ~/android-sdk/ ANDROID_NDK_ROOT Installation directory of Android NDK package. (WITHOUT ANY SPACE) Example: C:\AndroidNDK or ~/android-ndk/ ANDROID_SDK_HOME Location of SDK related data/user files. Example: C:\Users\<USERNAME>\.android\ or ~/.android/ ANDROID_EMULATOR_HOME Location of emulator-specific data files. Example: C:\Users\<USERNAME>\.android\ or ~/.android/ ANDROID_AVD_HOME Location of AVD-specific data files. Example: C:\Users\<USERNAME>\.android\avd\ or ~/.android/avd/ JDK_HOME and JAVA_HOME Installation directory of JDK (aka Java SDK) package. Note: This is used to run Android Studio(and other Java-based applications). Actually when you run Android Studio, it checks for JDK_HOME then JAVA_HOME environment variables to use.
Read more