Yeah, so when an error occurs, and an exception is thrown,
it's our job as developers to handle it by providing a backup plan.
We catch the exception and
fall back to some reasonable default behavior, otherwise the app may crash.
In other words,
some application crashes are simply the result of the uncaught exceptions.
>> Yeah, so in order to do this, we're going to have to learn about something
called the try catch block in Java.
>> Try means you try to execute a group of statements,
that includes calling a method that could potentially thow an exception.
>> And when an exception is thrown, you catch it.
If no one catches the exception, well your app will crash.
You okay, Joe?
>> I'm fine.
And regardless of whether an exception was thrown or not,
we can finish executing code in the finally block.
>> So the full flow is try to do something that may throw an exception,
catch the exception if it's thrown.
And finally, execute some code regardless of whether or
not that exception occurred.
>> We should show them some code for this.
>> Yeah, for sure.
Let's do it. >> In the Tsunami App there are multiple
examples of try catch blocks.
Let's look at one in the create your own method.
The goal of this method is to return a URL object for
the provided input string URL.
Ideally, we would just call a URL constructor and pass in the string URL,
but via this red squiggly line Android Studio is notifying us of
an error situation that is detected.
That is, it says that we have an unhandled exception of
type malformed URL exception.
This means that the URL constructor throws a malformed URL exception, and
we need to catch and handle the error.
Otherwise, our app won't build and we can't run it on our device.
For any constructor or method call,
you can check if it will throw an exception by checking the documentation.
For example, if we visit the URL reference documentation,
we can see that the URL constructor that accepts a string as input through
MalformedURLException.
If the input parameter can't be converted into a URL,
that is it is MalformedURL.
To fix our code, we can use the shortcut Alt+Enter for a quick fix.
We can select the option, surround with try catch, and
Android Studio will automatically update the code.
Pretty neat, right?
Now we have the key word try followed by an opening curly brace.
Inside the try block we put all of our code in here
that could throw an exception.
Now in general, it's good practice to keep code inside this block lean.
You don't want full method by this here,
then we close the block with the curly brace.
Next, we have the keyword catch followed a set of parenthesis
containing the exact data type of the excephamore catching.
In this case, MalformedURLException and the variable name for
the exception object e.
Then we have an opening brace where we will handle the exception,
e.printStackTrace will print the error stack in detailed format.
Another option is to log areas using Androids log methods and
include our own log tag and our own custom message.
The log.e method can take an exception as it's third argument.
To recap, if all went well on the URL constructor,
then no exception is thrown and nothing on the catch block ever runs.
But if the code within the try block throws an exception, then we immediately
jump to the cash block with the exception and execute the code there.
Then we exit the try catch statement and
continue executing the code line by line after that.
Notice that the URL variable is initialized before the try catch block.
We have to consider variable scope here.
If we define the URL variable inside the try block,
we won't be able to access the URL variable after the statement is done.
So since we want to reference the URL variable at the end of the method
outside of the try catch statement.
We need to initialize the URL variable outside of it as well.
In this case, we can just set it to null, which means an empty value.
So now we've seen how Android Studio will notify you if you need to wrap your
code in a try catch statement.
If you want more information,
you can check out the official Java documentation.
This next example is a little bit more complex.
It shows that you can have as many lines of code in the try block as you want.
If any line of that code throws an exception, then we stop executing
the statements in the try block and jump directly to the catch block.
As you can see here you can and should have
multiple catch blocks to handle different types of errors if necessary.
Here, the code catches an index out of bound exception and
prints a system log message.
The code also catches an IO exception and prints a different log message.
Now depending on what exception gets thrown,
we will fall into one of these catch blocks, but not both.
So you can see how there's no guarantee of executing
all of the code in the try block.
Sometimes you have clean up that needs to be done even if there was
an exception thrown.
So the finally block will always be executed regardless of whether or
not an exception was thrown.
Before we wrap up this discussion,
I want to point out one final method of dealing with a check exception.
Now as you can see here by modifying the createURL methods, methods signature.
You do have the option to defer the exception handling up the call chain
by declaring that your method may throw the exception
which in turn requires that the calling methods handle it.
This is common if the exception is thrown from inside helper method.
And you want to handle it in a try catch somewhere else.
For example, whoever calls the createUrl method will now need a try catch block
around this method call, and have to catch the MalformedURLException.
We can see this here in the doInBackground method.
For the purposes of the Tsunami App, if you call some Android framework code
that throws an exception, you should catch it and handle it at the moment
it happens instead of deferring it to be handled later.