news and informations automotive,business,crime,health,life,politics,science,technology,travelautomotive,business,crime,health,life,politics,science,technology,travel If any of you subscribe to the Android Developers mailing list you will often find people who post hundreds of lines of code saying that there is a problem, and asking for help. Now, this list is a community where developers like me take their own time out to help people. We are not paid to do so and it would be unlikely that anyone would spend time reading all that code. Mostly we would be more than happy to help if the person posting the question includes the relevant part of the LogCat and the code lines it mentions, perhaps pasting the entire method of that error line. This tutorial explains the LogCat, how to use it and find the relevant parts of the code and some of the most common errors displayed in the LogCat.
First of all let us look at looking at the LogCat. In the top right corner of your eclipse there will be two tabs. These will be “Java” and “Debug”. Click on the Debug tab. In all probability you will see two columns there. One will have “Console” and “Tasks” tabs and the other will have just one tab reading “LogCat”. If the LogCat one is not visible then go to Window -> Show View -> LogCat. Now start your debug run. After the emulator or device as loaded to a certain extent you should see something like this in the LogCat:

Nice and colorful isn’t it?
Your errors will be marked in red and generally be a block. See the example below. (The errors from your app will probably be around 10-20 lines)

These errors are what you need to post to lists and friends to get help.
Let us talk about filtering the LogCat. It is huge in size and it will often be a pain to go through all of it. There are four buttons on top that look like this:
The first button “V” stands for verbose and will display everything. The second one “D” stands for debug and will display all the messages that can be useful for debugging. Clicking this may not seem to change anything but it does, trust me on that. The third one “I” is info. It will display all the Information text, generally the errors, warnings and, well, info messages. The fourth one “W” is warnings. This will display only errors and warnings. The fifth and last one “E” is for errors. This will display only errors. Another way to filter it is to type something into the message text box below. There are a few more options that can be utilized only from the command line. The table below from Google covers all the options pretty well.
| Option |
Description |
-b <buffer> |
Loads an alternate log buffer for viewing, such as event or
radio. The main buffer is used by default. See Viewing Alternative Log Buffers. |
-c |
Clears (flushes) the entire log and exits. |
-d |
Dumps the log to the screen and exits. |
-f <filename> |
Writes log message output to <filename>. The default is
stdout. |
-g |
Prints the size of the specified log buffer and exits. |
-n <count> |
Sets the maximum number of rotated logs to <count>. The default value
is 4. Requires the -r option. |
-r <kbytes> |
Rotates the log file every <kbytes> of output. The default value is
16. Requires the -f option. |
-s |
Sets the default filter spec to silent. |
-v <format> |
Sets the output format for log messages. The default is brief format. For a
list of supported formats, see Controlling Log Output
Format. |
Now it is time for you to understand the LogCat. This is very easy but utilizing the information you gain can be very difficult. Let us start with the exception I have encountered most commonly. The NullPointerException. It looks something like the screenshot below.
This is most often caused if
1) Your variable does not exist
2) The variable has a null value when it should not be containing null.
The most important part comes after the Caused by line. Somewhere here you will see you package name and a pointer to the line on which the error occurred. Now you can go to that line and see what could possibly be null.
Let us move on to another error. The StackOverflowError. Sadly I couldn’t cause one on demand and so don’t have a screenshot. Anyways this error occurs when your app exceeds the stack limit of the device or emulator. This mostly happens if you get stuck in an infinite loop.It can also happen in a correctly written but deeply recursive program. The only way to solve it is to utilize less resources.
I can’t think of any other common errors right now but if you want me to elaborate on any other one then comment with the error name.
Acknowledgments: Thanks to Kristopher Micinski for bringing to my attention a few missing options. Table added as a result.
news and informations automotive,business,crime,health,life,politics,science,technology,travelautomotive,business,crime,health,life,politics,science,technology,travel