ok so continuing on as I mentioned in
the last video fortunately the debugger
does allow us or provides us with
otherwise to control the execution of
the application so you don't actually
have to add a breakpoint on each and
every line we actually do so
controlling this flow of execution
by the buttons on the toolbar directly
above the frames variables area down
here next to the debugger and console
tabs so let's go through what each of
these buttons do one by one from left to
right now for each button what we're
going to do is I'm going to try the
button out we're going to stop the
application using the usual stop button
and then run the debugger again so that
the application was spend at the break
point that started on so let's
look at this first one which is the show
execution point which is this one here
and it's going to hover over it show
execution points of actually tap this
one so this returns the editor to where
the application was suspended and it
didn't really do much there because I
was already actually on that line but if
we flip back to the main dot java code
for a moment let's presume that you're
editing another file now come back over
here again and click on this button you
can see it's quite handy and actually
takes us back to the current execution
line so it's basically the line
corresponding to the current breakpoint
now this may seem trivial but when
investigating a bug you may have
actually opened up several different you
know java source files while the
application was suspended and saves
you from having to flip back through all
them to find the current execution
points just really a shortcut to get
back to where that break point is the
next one is now the step
over this button will advance the
execution point by one statement and
won't show us
what's happening inside any methods
called by the statement i'm going to
close this and run it again debug
remember not normal run need to
go back to main is probably quicker to
do this here if that's the case click on
debug can see that's the current line so come
over here and look at this step over and
come down here and click that you notice
that we've moved on to the next line we
move onto line 12 now so the application
with that one line of
code that code on line 11 got
executed and then we skipped
over to the next line onto line 12 and
the application got suspended again
alright so we'll take a look at the
state later let's actually try it the
other buttons first and remembering
that each time we do this we close down
the app and run it again or debugger
I should say to be more precise this time
going over to this next one this is
different to step over this is step into
so this step into button will actually
step into any methods called by the next
statement that's executed so the
application will suspend on the first
line of the first called method now we use
the previous one the step-over we don't
care about what's happening in any
method called by our code but we use step
into when we want to actually see what's
happening inside that method any method
is called by a code lets actually press
this step into button in this case we
can see that the debugger didn't step
into the append method so behave much the same
as if we press the step-over button but
this actually happened because the
stringbuilder . append method is a method of
the java development kit so many
debuggers including the IntelliJ
debugger won't suspend within jdk
methods because they assume that developers
aren't interested in seeing what's
happening inside those methods the jdk
isn't bug-free but most of the time it
won't be the source of a bug the
situation could also arise when we're
dealing with third-party libraries now
if you want the debugger to spend within a
jdk method or another method
that normally it would skip over we have
to use the four step into button which
is next one now this button will force
the debugger to step into a jdk method
and suspend so lets actually see how that
works i'm going to stop the program and
then we're going to debug it again
starting it debug icon so this time
we're going to click on the force into
force step into click on that you can see here
that now we've used force step into you
can see that this time the debugger
steps into the append method we can
actually see the jdk method
for the append from the stringbuilder class
the code that is going to be executed
and use the step out button when you
want to debugger to read to run the
rest of the method return to the caller
and suspend so moving on now to the next
button to step out now we use the step
out button when we want to debugger to
run the rest of the method to return to
the caller and then suspend so when we try
this now I haven't restarted this time
we click on that
notice what happens its gone back to the
line where we originally got called from the
add char method from the string
utilities now this is a case which i
mentioned in the previous video where
the highlighted line of code has been
executed so there's a scenario here
where it looks like the debugger may or
may not have executed in this case we
have executed because we use the Force
step into to go into the method then we
use the step out to come back to this
method so this point in time the dot
append has been processed we called
alright so moving over to the next one
this is the drop frame now the drop
frame button allows us to effectively
time travel into the past and what I
mean by that is it lets just rewind the
application by one frame now if we were
to rewind the frame here we actually
jump back to the main method as if the
add char method had never been called the
application would be suspended on the
line that called the method but an
important note here is we can't rewind
everything in for example network
traffic database changes and changes to
static and instance variables won't be
undone only changes to local variables
will be reverted so some developers use
it to try out different code paths
without having to restart the
application but to be honest most of us
will probably never use it will give it
a try just to confirm and you can see
that we've moved back to the main method
at this point in time and suspended
before the highlighted line of code is executed
again we could confirm that by stepping
step over and gone back into the method
again in back to drop frame again and
we're back to the main method
alright so finally this is last one over
here which is run to cursor let's say
we've got a method
that's say a hundred lines long and we
suspended on line twenty we want to run
to line 55 and then suspended again
we could set a break point online 55 but
setting a lot of breakpoints can make
future debugging session a bit of a
pain and also if you forget to remove
them the application will suspend in
places we weren't expecting so unless we
actually think we going to want to suspend
om that line 55 again it would be better to
put our cursor on line 55 and use run to
cursor the application will run and when
it reaches the line where the cursor is
located it will actually suspend lets
actually put our cursor what we do is
we stop and we'll run it again debug it
again let's put our cursor now on the
chars added plus plus line down here
come over here and click on the run to run to
cursor the application is now suspended
on that line those buttons are quite
convenient but if you prefer to use
menus we do all of this from the main
menu come up into the run run menu as
you can see here we've got step over for
step in to step into force step theirs
a couple of other ones their as well you can
see that pretty much all there as well
as resuming the program as well but
we talking more about some of these
options shortly
now what do we do though if we suspended
and we found the bug so we don't want to
step over or into or out
we just want to get out of the debugger
so you can just stop the debug session
as we've been doing but it's not always
a good idea now for our little application
is fine but for an application that's
perhaps connected to a database or
that's opened up a network connection or
has any type of cleanup that it needs to
do is better to run the application to
completion and we do that by pressing on
the resume button to the left of the
frames area down here resume program
will actually run it through to the end
as long as there's no other breakpoints
that program will run it complete
and again the case over here there's
also the resume program as well and you
can see there's a shortcut down on the
mac at least command option r so again
there's no the breakpoint breakpoints
clicking on this resume
will actually run the program
in complete and if we've set other break
points though the application might
suspend again and that's why it's good
to keep break points to a minimum and
use run to cursor in most cases it can
be easy to accidentally press the run
program button when we want to resume
the program now doing so runs an
entirely different instance of the
application so we can get back to the
debugger by clicking on down here which
of course is just above the status bar
on the ides main window so if you
accidentally run it again you'll be
over here and you come back and click on
debug to get back to the debugger now if
you're finding that you've got a
lot of breakpoints and you want to get
rid of some of them there's a way to see
all breakpoints in our application we
actually go up here to the run
menu and click on View break points
down here you can see that this dialogue
opened and shows all the current
breakpoints and in the case of
intellij if you got it configured for other
languages we're going to be seeing some
of the other languages python
exception and so on and so forth but
right at the moment we can see that
we've got a break point on string
utilities java line 11 that's consistent
with the breakpoint that we've got there
showing online 11 so from this screen
now the point that I wanted to show you
what you can remove any breakpoints by
checking the box next to them you can
also add break points but only certain
types of breakpoints because we really
have to be able to specify where the
break point should go so we can't set
breakpoints on statements within a
method using the dialogue so let's
actually close that now without changing
anything so i click that but i clicked
again to leave it on
click on done but note that we can also
get to the view breakpoints dialogue
that's this little button over here and
click on that opens up the same dialogue
and just wanted to re affirm them come up
here you click on rerun it can be
actually easy to do that because it's
actually very similar to a very close to
the resume program so keep that in mind
that can be common problem by clicking
debug will take you back to that screen
if appropriate
alright so let's end the video here now
in the next video we're going to go
through a little bit more and start
using some of these things that we've
learned to debug this app and see if we
can fix the problem that has been introduced
into the code so i'll see you in the
next video