Original subtitles

Now sometimes you have a really hard time finding an error, especially if it's not an error that throws

an error message but if it's some logical error.

Now what would be an example for a logical error?

An example would be that we indeed add 2 here because maybe we mistyped and we'll now never get an error

message because I commented out that line and in our widget tree, we also won't run into a situation

where we select the wrong question because we render the results screen

once we're out of questions or once our index exceeds the questions length, so we'll never get an error

message here and still, we have the wrong behavior.

When we test our app on the device, we see we seem to skip a question and we only got two questions until

we reach the result screen.

So something is wrong but here we got no error message,

so how can you now narrow down the issue and find out what's wrong?

There are two ways of doing that,

the quick and dirty way is that you use print. Here for example, you could print question index to find

out if something's wrong with that index.

So we could do that here

and if I save that and I now click through my question or for my answers again, then we see that

the question index is 2 and 4 and that might already be all we need to know to find out oh something's

wrong with the index,

why is it increasing by 2, it should be increasing by 1.

So this might be one way, using print in your code is a nice way of printing out the current state of

a given value and find out if it has the value you would have expected.

But if you have more complex problems, using this print debugging can be too cumbersome and therefore,

you should use the more powerful built-in debugger. For that, quit the running app and now run the

app in debugging mode, so start debugging, not start without debugging but start debugging or use the

respective shortcut.

Now this will also launch the app but as you can already tell, in a different mode. Here in

Visual Studio Code, it automatically enters the debugging view which you can also activate manually here under

view debug,

you can always go back to the explorer if you want to see your files but in view debug, you now can

do more than just add a couple of print statements,

for example what you can do now is set breakpoints. You do that by moving your mouse cursor to the left

side of the line numbers here in your editor view and then you can add a breakpoint by simply clicking

there.

Now a breakpoint will halt the code execution whenever it reaches this code line and you can then even

look into the values of variables and properties and find out if everything has the value you expected

and so on.

You can also, if you want to, place breakpoints here in your widget tree, simply try a couple of different

spots and see where code execution stops.

So now let's wait for this installation to finish, for the build process to finish and let's see how the

breakpoints work. Here

the app already stopped,

it launched the app and it stopped right away because I placed a breakpoint in my main.js file, in my

MyAppState class, in the main build method

therefore right here when the widget tree gets built. And now you can use the controls here in the top

right on this bar to move through your code.

With this icon here, you move through the next line of code, so to the next instruction to be precise.

With the arrow next to it, you can step into,

for example a function call, so that you don't skip it and just proceed with the result but that you

really can go through each step in the function

and if you are in such a function for example, you can use this arrow here to step out of it.

So here, I'm in the build method of the quiz widget now because I stepped to the next step,

we see that now here build was called and the cool thing is we can now step into this and if you hover

over things like the context here or over questions, you can see what's in there.

You can inspect this, you can find out what values are in there and if that all has the values you

did expect,

for example we can find the current question index value.

You can also add values to the watch list here on the left

so that you can watch how they change as you progress through code.

So here for example, I could add question index and now you see it currently has a value of zero and

we can check whether it stays that way.

Now once you're done for the moment, you can always press the play button here on the left to continue

code execution until the next breakpoint is hit and you see right now, question index is not available because

we're not in that code snippet anymore. Now

however if I press a button, I'm taken back to the editor because I also had a breakpoint in answer question,

I placed that earlier

and here, we can now see what the total score is for example, we can see what the question index is

and here we might then already spot our mistake for example, our logical mistake. Again, we can step through

our code step-by-step if we want to,

so that we progress step-by-step. We always can see which variables we currently have in the method

we're at the moment, so score for example or this which refers to the overall class where we can therefore

inspect all our properties of that class, bunch of internal properties managed by Flutter but then also

for example our _questions or our question index property and with these tools, you should

have everything to deeply analyze your code, what's going on there, what's changing, why it's changing and

hopefully spot logical mistakes.

Now if you're done, you can always press the play button and if you want to get rid of breakpoints, you

simply click on them to clear them and now your code won't stop there anymore.