Day97 of #100DaysOfCode

Day97 of #100DaysOfCode

Hii folks 🙌

Today I will be continuing the same pathway in which we will learn to set conditions for the breakpoint.

Unit 4: Internet

Pathway 2: Get and Display Data

https://developer.android.com/courses/android-basics-kotlin/course

Set conditions for breakpoints

In the previous section, we had to step through each iteration of the loop until the denominator was zero. In more complicated apps, this can be tedious when we have less information about the bug. However, if we have an assumption, such as the app only crashing when the denominator is zero, we can modify the breakpoint so that it will only be reached when this assumption is met, rather than having to step through each iteration of the loop.

• If necessary, we will introduce the bug by changing 4 to 5 in the repeat loop.

repeat(4) {
    ...
}

• Place a new breakpoint on the line with the repeat statement.

• Right click on the red breakpoint icon. A menu will appear with a few options, such as whether or not the breakpoint is enabled. A disabled breakpoint still exists, but won’t be triggered at runtime. We also have an option to add a Kotlin expression that if it evaluates to true, the breakpoint will be triggered. For example, if we used the expression denominator > 3, the breakpoint would only be triggered on the first iteration of the loop. To only trigger the breakpoint when the app is potentially going to divide by zero, set the expression to denominator == 0. The options for the breakpoint should look like the following:

• Run the app using Run > Debug ‘app’ and observe that the breakpoint is reached.

• We can see that the denominator is already 0. The breakpoint was only triggered when the condition was met, saving the time and effort to step through the code.

• Like before, we see that the bug is caused by the loop executing one too many times, where the denominator was set to 0.

Add watches

If we want to monitor a specific value while debugging, we don’t need to search in the Variables tab to find it. We can add something called Watches to monitor specific variables. These variables will be visible in the debug pane. When execution is paused and that variable is in scope, it will be visible in the Watches pane. This makes our debugging more efficient when working with larger projects. We’ll be able to keep track of all the relevant variables in one place.

• In the debug view, to the right of the variables pane, there should be another empty pane called Watches. Click the plus

• Button in the top left corner. We may see a menu option that says New Watch.

• Type the name of the variable, denominator, in the provided field and click enter.
• Re-run the app with Run > debug ‘app’, and observe that when the breakpoint is hit, we’ll see the value of the denominator in the Watches pane.

That is all for Day97 ✅

Thanks for reading, See you tomorrow!