Problems with your apps will not always be crashes. In some cases, they will be misbehaviors. For example, suppose that every time you pressed the NEXT button, nothing happened. That would be a noncrashing, misbehaving bug.

In QuizActivity.java, make a change to the mNextButton listener to comment out the code that increments mCurrentIndex.

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    ...
    mNextButton = (Button)findViewById(R.id.next_button);
    mNextButton.setOnClickListener(new View.OnClickListener() {
        @Override
        public void onClick(View v) {
            // mCurrentIndex = (mCurrentIndex + 1) % mQuestionBank.length;
            updateQuestion();
        }
    });
    ...
}

Run GeoQuiz and press the NEXT button. You should see no effect.

This bug is trickier than the last bug. It is not throwing an exception, so fixing the bug is not a simple matter of making the exception go away. On top of that, this misbehavior could be caused in two different ways: The index might not be changed, or updateQuestion() might not be called.

If you had no idea what was causing the problem, you would need to track down the culprit. In the next few sections, you will see two ways to do this: diagnostic logging of a stack trace and using the debugger to set a breakpoint.

In QuizActivity, add a log statement to updateQuestion().

public class QuizActivity extends AppCompatActivity {
    ...
    private void updateQuestion() {
        Log.d(TAG, "Updating question text", new Exception());
        int question = mQuestionBank[mCurrentIndex].getTextResId();
        mQuestionTextView.setText(question);
    }

The Log.d(String, String, Throwable) version of Log.d logs the entire stack trace just like the AndroidRuntime exception you saw earlier. The stack trace will tell you where the call to updateQuestion() was made.

The exception that you pass to Log.d(String, String, Throwable) does not have to be a thrown exception that you caught. You can create a brand new Exception and pass it to the method without ever throwing it, and you will get a report of where the exception was created.

Run GeoQuiz, press the NEXT button, and then check the output in Logcat (Figure 4.3).

Figure 4.3  The results

The top line in the stack trace is the line where you logged out the Exception. A few lines after that you can see where updateQuestion() was called from within your onClick(View) implementation. Click the link on this line, and you will be taken to where you commented out the line to increment your question index. But do not get rid of the bug; you are going to use the debugger to find it again in a moment.

Logging out stack traces is a powerful tool, but it is also a verbose one. Leave a bunch of these hanging around, and soon Logcat will be an unmanageable mess. Also, a competitor might steal your ideas by reading your stack traces to understand what your code is doing.

On the other hand, sometimes a stack trace showing what your code does is exactly what you need. If you are seeking help with a problem at stackoverflow.com or forums.bignerdranch.com, it often helps to include a stack trace. You can copy and paste lines directly from Logcat.

Before continuing, delete the log statement in QuizActivity.java.

public class QuizActivity extends AppCompatActivity {
    ...
    private void updateQuestion() {
        Log.d(TAG, "Updating question text", new Exception());
        int question = mQuestionBank[mCurrentIndex].getTextResId();
        mQuestionTextView.setText(question);
    }

Now you will use the debugger that comes with Android Studio to track down the same bug. You will set a breakpoint on updateQuestion() to see whether it was called. A breakpoint pauses execution before the line executes and allows you to examine line by line what happens next.

In QuizActivity.java, return to the updateQuestion() method. Next to the first line of this method, click the gray bar in the lefthand margin. You should now see a red circle in the gray bar like the one shown in Figure 4.4. This is a breakpoint.

Figure 4.4  A breakpoint

To engage the debugger and trigger your breakpoint, you need to debug your app instead of running it. To debug your app, click the debug button (represented by a bug), which is next to the run button. You can also navigate to Run → Debug 'app' in the menu bar. Your device will report that it is waiting for the debugger to attach, and then it will proceed normally.

Once your app is up and running with the debugger attached, it will pause. Firing up GeoQuiz called QuizActivity.onCreate(Bundle), which called updateQuestion(), which hit your breakpoint.

In Figure 4.5, you can see that this editor has opened QuizActivity.java and highlighted the line with the breakpoint where execution has paused.

Figure 4.5  Stop right there!

The debug tool window at the bottom of the screen is now visible. It contains the Frames and Variables views (Figure 4.6).

Figure 4.6  The debug tool window

You can use the arrow buttons at the top of the view to step through your program. You can see from the stack trace that updateQuestion() has been called from inside onCreate(Bundle). But you are interested in investigating the NEXT button’s behavior, so click the resume program button to continue execution. Then press the NEXT button in GeoQuiz to see if your breakpoint is hit and execution is stopped. (It should be.)

Now that you are stopped at an interesting point of execution, you can take a look around. The Variables view allows you to examine the values of the objects in your program. You should see the variables that you have created in QuizActivity as well as an additional value: this (the QuizActivity instance itself).

You could expand the this variable to see all the variables declared in QuizActivity’s superclass, Activity, in Activity’s superclass, in its super-superclass, and so on. But for now, focus on the variables that you created.

You are only interested in one value: mCurrentIndex. Scroll down in the variables view until you see mCurrentIndex. Sure enough, it still has a value of 0.

This code looks perfectly fine. To continue your investigation, you need to step out of this method. Click the step out button.

Check the editor view. It has now jumped you over to your mNextButton’s OnClickListener, right after updateQuestion() was called. Pretty nifty.

You will want to fix this implementation, but before you make any changes to code, you should stop debugging your app. You can do this in two ways: You can stop the program, or you can simply disconnect the debugger. To stop the program, click the stop button shown in Figure 4.6. Usually it is easier to simply disconnect the debugger. To do that, click the close button also labeled in Figure 4.6.

Now return your OnClickListener to its former glory.

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    ...
    mNextButton = (Button)findViewById(R.id.next_button);
    mNextButton.setOnClickListener(new View.OnClickListener() {
        @Override
        public void onClick(View v) {
            // mCurrentIndex = (mCurrentIndex + 1) % mQuestionBank.length;
            updateQuestion();
        }
    });
    ...
}

You have tried out two ways of tracking down a misbehaving line of code: stack trace logging and setting a breakpoint in the debugger. Which is better? Each has its uses, and one or the other will probably end up being your favorite.

Logging out stack traces has the advantage that you can see stack traces from multiple places in one log. The downside is that to learn something new you have to add new log statements, rebuild, deploy, and navigate through your app to see what happened. The debugger is more convenient. If you run your app with the debugger attached, then you can set a breakpoint while the application is still running and poke around to get information about multiple issues.

As if that were not enough choices, you can also use the debugger to catch exceptions. Return to QuizActivity’s onCreate method and comment out a line of code that will cause the app to crash.

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
    ...
    // mNextButton = (Button) findViewById(R.id.next_button);
    mNextButton.setOnClickListener(new View.OnClickListener() {
        @Override
        public void onClick(View v) {
            mCurrentIndex = (mCurrentIndex + 1) % mQuestionBank.length;
            updateQuestion();
        }
    });
    ...
}

Now select Run → View Breakpoints... to pull up the breakpoints dialog, as shown in Figure 4.7.

Figure 4.7  Setting an exception breakpoint

This dialog shows all of your currently set breakpoints. Remove the breakpoint you added earlier by highlighting it and clicking the - button.

The breakpoints dialog also allows you to set a breakpoint that is triggered when an exception is thrown, wherever it might happen. You can limit it to only uncaught exceptions or apply it to both caught and uncaught exceptions.

Click the + button to add a new breakpoint. Choose Java Exception Breakpoints in the drop-down list. You can now select the type of exception that you want to catch. Type in RuntimeException and choose RuntimeException (java.lang) from the suggestions. RuntimeException is the superclass of NullPointerException, ClassCastException, and other runtime problems, so it makes a nice catch-all.

Click Done and launch GeoQuiz with the debugger attached. This time, your debugger will jump right to the line where the exception was thrown as soon as it happens. Exquisite.

Now, this is a fairly big hammer. If you leave this breakpoint on while debugging, you can expect it to stop on some framework code or in other places you do not expect. So you may want to turn it off when you are not using it. Go ahead and remove the breakpoint now by returning to Run → View Breakpoints....

Undo the change from Listing 4.6 to get GeoQuiz back to a working state.