so although we only included a single statement in each of the try blocks that
we've use so far we could see an example of that on line 43 we've just got the
return s nextInt you can actually write many lines of code in
a try and similarly the catch block contains as much code it can contain as much
code as you need to handle the exception including attempting to recover from it
if that's appropriate for that particular bit of code but let's take a step
back and answer question what is an exception now the Java documentation defines
an exception as an event which occurred during the execution of a
program that disrupts the normal flow of the program's instructions so I guess
that could be summarized more simply as something went wrong somewhere which is
possibly a more useful definition because it leads more naturally to two
very important questions a. what went wrong? and b. what can we do about it?
so exception and runtime exception are classes defined in Java.lang and the
different types of exceptions that can be called a sub classes of one of these two
exceptions so normally when catching an exception you'd specified which subclass of
the exception to catch and we saw that earlier with this code on
line 43 when we caught the input mismatch exception with the invalid integer so
we could just catch exception but it's really a good idea to
be more specific and catch the specific exception rather just generalizing
catching sort of the catch-all catch so to speak with exception so in other
words we could have change the code to just be that and that will work fine but its very
generic and we are not being specific enough and it can be useful to actually be
specific and you see I'll be talking more about that
later on so the type of exceptions thrown answers the question what went wrong so that's
the other reason one good reason to use that and you can see on line 45 we know that at a
glance oh ok there's an input mismatch and that's because the
exception is being named to really make us understand the type of errors that's been encountered in the
program so when a code got an input mismatch exception we can then decide
what to do about it so as it happened the code didn't do very much you
know any invalid input just resulted in zero being returned now this could be a
reasonable response in some situations but in others calling method might need to
know if there was a problem rather than effectively being told that the user
entered the number 0 which is what we did here so to let the calling method know
there was problem the code could have thrown the exception what that
means is passing the exception back to the calling method so once again these
things are probably best explained examples so far we've created a
method to perform division and another method to get the number from the user
so by putting them both in the same program we can look at how exceptions propagate
after call stack and also explain what that means what call stack actually means as well
now we don't need the LBYL code and will start without handling any exceptions
just so we can see how Java handles things the main method is gonna call
divide which will call getInt twice to get the two numbers X&Y so this is getting a bit messy so
what I might do is create another bit of Java class so will put a new one in and calls this example and
lets type this in.....
...and that
method.....
....
.....
......pretty simple program there
...and run it first just to make sure that works
...so we do 10 second one 5 10/5 is 2 so x is 10 and y is 5 so that is
obviously working correctly but if we run it again and do it in the other way round.... 5 divided by 10 is 0 again
because we're using integer division here but there are two exceptions that could
happen in this program so just demonstrate that firstly if we just try and
divide by 0 so....notice the error their is arithmetic exception
divide by 0 and if we run again and instead of a number put something else we get a
different exception we get an input mismatch exception so as expected
we got an error because we saw that in the previous video and Java automatically
prints a stack trace which is showing the call stack so the call stack is a
list of all the methods all the method calls at any particular point in a
program's execution now in this case it's all the method calls at the point where
the program crashed so each thread of execution has its own call stack and the
thread is shown as the first line of the stack trace and here its our main thread
so every time a new method is called it's actually placed onto the stack and when a
method returns its then removed from the stack so here we can see that the
exception happened in line
864 in the throw for method of Java.util.Scanner throwfor I should say so we will have a
look at throwfor in a minute but our code didn't call it so it doesn't make much sense to us yet the
next item on the stack is scanner.next we didn't also call that either directly
so in fact the best approach to make sense of these traces is generally to start at
the bottom and then work back up so our first code which is on line 11 is the first
item relates to our Code of so its obviously is the com.timbuchalka.example.main
so line 11 in example is the first item that relates to our code and line 11 is
where the divide method was called and the trace shows that it
happened in Example.java so the next entry is line 16
in example.divide and that's where getInt was called and then the next one
after that is on line 25 of getInt so normally it would stop there because all the
entries above that are also out of our code in Java.util.scanner
class now we know that our attempt to get an integer from the keyboard failed
and we should do something to prevent that error from crashing the program
but carrying one through the stack at the moment because it's useful to see
just how to trace errors through different classes and packages so up until this
point IntelliJ has created links to the line numbers where they appear in the code in
the editor so the links appear in blue as you can see on the screen there in the stack
trace and you can click it to be taken to that line of code so for example we can just
click on this one and we get taken to that line of code you can see the cursor moved and likewise if click here we get back to
line 11 so once the trace leaves that code they may still be links but they are in gray
as you can see the first one where it says Scanner.java.2076 its in gray rather than
the blue and that is of course if you using these IntelliJ them it might be
different if you themed your IntelliJ installation separately so next we have
looking up the call stack on line 2076 Scanner.java so click on the link for that and I'll just move this over
so we can see a little bit more fully and IntelliJ has helpfully loaded the sources scanner and has taken us
to that line we could also control click on the call or command click to next int
on line 25 back in the code to do the same thing so the scanner nextInt method has
been overloaded which is why their seems to be 2 calls in the stack trace you can
see these calls here 2076 and 2117 and our calls are passed on to
nextInt(defaultRadix) as you can see their so we click on that
again and do a command click and do a control if your on a linux or windows that takes us to that method
and we get to the overloaded next int method so that entries is call to next as you can see and
looking up here the next call then goes to scanner.java
line 1485 so if you wanted to you can come back here click on the scanner.java 2117 and notice the input
mismatch exception that gets thrown and then come back here to next ther is a throw for
there and that's the code that's been executed here so we can click on that then
line 864 following that through and ultimately the input mismatch exception
on line 864 is we're it actually throws a new input mismatch exception so quite
often the exception will be thrown from the method that had the problem but as
you can see the scanner class uses the throwfor method to throw either a
mismatch exception or a np such element exception as you can
see here so depending on what the problem was
it's thrown one of two different exceptions so we are going to be talking more
about throwing exceptions later but for now I'm gonna concentrate what happens
when once thrown and how to handle them so I said that exceptions are
subclasses of the exception class and exception itself actually extends
throwable so will trace the classes back in a minute to see this but at this point
you just really need to know that the throwable constructor fills in the stack
trace for the exception so line
864 that you can see on the screen for Scanner.java creates a new input mismatch exception
object that contains the current stack trace so when the exception itself has
thrown the Java Runtime then looks to see what you know what can handle it so
it does that by working it back up the call stack so each method on the stack gets
the exception if it doesn't handle it
than the exception gets passed on to the previous method on the stack and so on
so the exception is set to propagate the call stack it keeps getting passed to
the calling methods until their is one that actually can handle the exception so
looking at the way the stack trace is printed
it might make more sense to talk about propagating down the call stack
but stacks tend to be implemented growing downwards so we talked about going back
up the stack
eventually if nothing handles the exception in the the main Java entry
point just prints the stack trace and the Java Runtime terminates and that's
what actually happened here to the right hand side of the screen so in a minute we are gonna modify the program to
catch the exception but first let's continue backtracking to see the
exception class hierarchy so from line 864 of the scanner class we are gonna click on
input mismatch exception so doing command click but do control click if necessary
click on that and you see we are now in the input mismatch exception constructor
and as classes go here you can see its pretty basic theirs 2 constructors and each one just delegates
immediately to the super but if we control click on super
get to the base class no such element exception it's just a sparse and in fact
exception objects are generally like this
the subclasses exists to provide more granularity so that code can check the
different types of errors by catching the subclasses so we saw no such element
exception before its the other exception that the throw for method could throw so input mismatch exception
extends no such element exception and exists purely to allow the exception
handler to differentiate between the scanner running out of input and the
input being invalid so we can cause a no such
element exception in our program but this video is getting a bit long so will start at looking at
doing that in the next video