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.