ok so moving on lets just see if we can actually get the no such element
exception to actually kick to basically be invoked as an exception in our error as an
exception in our program so firstly if we run the program we enter something
invalid
we get the input mismatch exception but that's not the error the one we
actually want is no such element exception so could we do that well
let's just try running again instead of typing in some something that we know
that isn't a number theirs another command you can type you can press Ctrl D on a PC or Linux
machine while your in the run window on a Mac I'm going to press Command D I wanna do
that that's going to actually send the ASCII EOT end of transmission
character to the program and then abruptly terminates any input so just do that
to confirm that works we can see their command D has been showing and I'll
just run that again so its clear what's happening and look at the green little output that when I
actually click on I'm pressing command D again you do control D on a
Windows or Linux machine you will now send a EOF file command d and its control + d for
windows and linux was sent through but the point is we've now got the no such element
exception thrown because of that so by subclassing the no such element
exception the creators of the scanner class allowed programs find the control
of how they respond to the exception so we got multiple exceptions actually happening
here so again going back into the scanner class and we go and click on the
no such elements exception notice how it extends the runtime exception and click
on super
we are now in the runtime exception and notice how the super is being called if I click on super
again we should get straight to exception which is sort of the the base
class it actually action extends throw but not another exception so we can go through again
into exception by clicking on the super
we get to throw-able and you can see now that the throw-able is actually got a method in to
fill in stack trace so as a result as long as the subclass exceptions
constructor calls super the stack traces automatically gonna be available and
output like you can see on the screen there now there are other constructors for
most of these exceptions and you may have caught a glimpse of that as I was quickly
clicking through and these can allow method to add more information to the exception
before throwing it to its calling method but really getting ahead of myself here
so lets just go back and modify the program to start catching the exceptions and
look at the options we have for dealing with them so close this run window
down and will close throw-able for we don't need half of these so close all these other ones
down they are part of Java and just get back to our Code ok so we're back in our example.java now so let's look
at getInt method starting at the this lowest level of the program the
getInt method can get an exception when theirs no more input available or when the input
doesn't represent a valid integer now we could catch the exception but if we did what will
we do with it
generally speaking there's no point catching an exception unless your code can do
something sensible with it as a result and here theirs really no action that can be
taken if theirs more input available so catching the no such element exception
is therefore really a waste of time in this method the only really sensible
thing to do with it is to allow it to propagate to the calling method and that
would happen automatically if we don't catch it now a little later and I'm going to discuss the two
different types of exceptions and will see that sometimes you may want a deal
with the exception in some way even if you only want to propagate it now as I
mentioned IO is a good source of potential errors so it makes more sense
to discuss checked and unchecked exceptions using more realistic
examples but our exceptions here are unchecked and we can just allow them to propagate
automatically if we can't handle them sensibly in a particular method now theirs
a possible action that we could take if we get an input mismatch exception we
could request another integer from the user so let's make some changes to the
getInt method to do that
so we're going to instead of just returning s.nextInt lets have a method to continually
asked for input until we got something valid so the way to do
that's pretty straightforward we put...so basically that means we talked about
this before but it's going to continue executing until we specially break out of
it
then we are going to put...
....
....so we need to do a s.nextLine which we talked about in
previous videos to basically read passing the lines so we can actually
start fresh and put...
.....
....and that's gonna be invoke the code on line
28 if its valid if they have typed a number in and the code basically
from line 30 to 32 is only going to be invoked in used if their was actually an
error so lets run that first and check the it does work ok and you can see on line
17 and 18 its asking for 2 integers so we can enter the first one correctly second one
correctly x is 123 y is 124 so that's working out ok and if we check it again
put something invalid in ABC
its continually asking that we entered something invalid....again its working quite nicely...and answers ultimately to so bear in mind that you know
I'm explaining about exception handling here but it is very difficult to be able to
guarantee an exception dividing by zero in scanner.nextInt method is two ways I
can be sure I'm generating an error which is why I'm using them in this example
but this get.newInt method is very wrong for several reasons so please do
not use this as an example
of how to get input from a users in a real program the later examples is gonna do that much
better and just to confirm if we run it one more time will see what happens with valid and invalid
input I can do the command D which is CTRL D on PC running Windows or
Linux we can exit we get the no such element exception and note how that wasn't
trapped with our exception here because we already caught the input mismatch
exception and we've put some code in automatically but the no such
elements exception wasn't caught and went back up to chain as we talked about
before and the reason we did that we decided to it will be left for the calling
method to handle that error rather than actually handle it in the getInt class itself now the calling method is
divide and as well as receiving an exception from getInt it can also get one by
attempting division by zero and once again there's really nothing sensible
that this method could do with either exception because if a method can't
perform the function that it's supposed to perform then the only thing it can you know
realistically do is inform its caller about the error so the first attempt
earlier returns 0 but this was part of I say an aircraft navigation
system and it return 0 when it really meant I did something and it got on fire and my sensors burnt out
you can see that the consequences could be quite serious but in this case we are
looking at exception so I'm going to press on so lets really annoy the user at this
point by attempting to catch the no such exception
and insisting that they enter number so the first attempt to this could be something
along those lines lets look at the divide method again add a try.....
...
now this is very common when adding a try block to code because you can see now
that x has suddenly become a declared on line 21 and 24 it happens because a try block
is the same as any other java block as far as scope is concerned so what would
really need to do is to declare x outside of the try so we need to put.....
....
...so if we run this firstly checking that it works correctly for the valid inputs
and running again and this time if I try and exit
with my command D well it still crashed that's because although we caught the
first exception our exception handler then attempts to retry the operation
that caused the problem by calling getInt again and this results in a second exception
which isn't actually caught so that's why its crashed the second time so you know it
is valid for an exception handler to try and recover from an error condition but
it's important to make sure that any code in the exception handler the catch
block in other words doesn't actually cause exceptions itself so control D is
close the programs Input Stream so even though getInt creates a new scanner any attempt
to read from it will continue to raise no such element exceptions in this case thats
just a feature of scanner essentially so the upshot is that we really shouldn't have
tried to do that their in the catch block and of course we already decided it
was a bad idea for other reasons but I went ahead and did it anyway really just to
demonstrate the importance of ensuring that exceptions are not raised in New
exception handler code itself a catch block is there to catch one or more
exceptions and as the name implies exceptions are things you should not
normally happened
in the general scheme of things but we should guard against them in case they do keep
them simple to try to make sure that they won't cause more exception is
really the rule here so it is possible to nest a try catch block inside a catch block and
you know sometimes it can be useful to do so but the best advice I can give you
is to keep your catch blocks as simple as possible the less code their is that a catch
block the less chance of it theirs another exception being thrown so its pretty
obvious that we can't do anything sensible inside the divide method if
we get an exception for getting it and we already decided that there's nothing we
can do with an attempt to divide by 0 either so we could let both the no such element
and arithmetic exceptions automatically propagate up the call stack and let the
main method handle them both but what we can do is make life easy for us by
throwing a single exception in both cases so this is a good opportunity for you
to see how the throw exceptions anyway so to throw an exception
we create a new exception object and use the throw statement generally you should try
to be specific as possible and use an appropriate subclasses exception rather
than throwing exception itself now as our divide function performs integer
division
throwing arithmetic exceptions seems like a good choice so we can also use the overloaded
constructor that takes a string for the exception so that we can provide a bit
more information on what actually happened now this is not really intended
for the calling method but its useful in log files when a human has to work out
what happened so we should also include the second call to getInt inside the try
block so to do that would have to declare y the same way we've declared x
so lets just go ahead and clean up our divide method so....
.....
and obviously whatever you want to put their that's going to be will be able to see on
the screen so that's the first when retrieving the data and also after
outputting the result the input we got another try block so.....
....
...and run this first we try exit so do a command D now notice how we got an exception
thrown exception in thread main no suitable inputs so that's our first
exception now being generated which is good so you can see it's working and we close it
down again and run it again and this time will put in a valid number but make sure the second on is 0 and we get
our arithmetic exception attempt divide by zero so that is clearly that's working as well so
when the programs run and either the 2 exceptions are true as you saw the stack traces is then
much simpler actually I'm not sure if you've notice that so ill do it again so you can see it but noticed the stack
traces is a lot simpler now its really only referring to our code and that's because
the exception originated in the divide method so Java doesn't need to
show any other methods that were being invoked the code we've written though
looks clumsy and will look at fixing that up in the next video