All language subtitles for 031 Unchecked Exceptions_en

Unchecked exceptions happened during the runtime.

There are two types of exceptions, checked exceptions and unchecked exceptions in the previous lesson,

you learned to catch checked exceptions, but in this lesson you're going to learn to fix unchecked

exceptions.

Both checked and unchecked exceptions are failures.

I checked exception is a failure that's outside the control of the application, so Java is going to

force you to try to run the code and catch the exception if it fails.

An unchecked exception is the result of badly written code, never, ever catch an unchecked exception,

catching an unchecked exception is the same as sweeping the problem under the rug.

If your code is badly written, don't cover the problem.

Instead, fix your code so that it doesn't fail.

Unchecked exceptions are runtime exceptions.

In other words, the failure happens while the app is running and will crash your application.

The most common examples are right index out of bounds.

Exception, null pointer exception.

A legal argument.

Exception in mismatch exception.

An illegal state exception.

There are so many more.

Let's have a look at each one.

Go to this path in your resources and open unchecked exceptions, and if you're missing this path for

whatever reason, make sure to download the updated resources from GitHub.

The array index out of bounds exception is thrown if you index outside the bounds of the array.

So inside runtime, except you one Java, we're going to try to index the fifth element from an array

that stores only three elements.

And it crashes the application, throws an array index out of bounds exception.

Now, there are two things we can do.

You can try to run this code.

And catch the exception if it fails.

We're going to catch the array index out of bounds exception and print the message that it comes with.

This time, the application doesn't crash.

The code fails and throws an exception, but we're catching the exception and printing its message.

And that being said, never, ever do that, never catch an unchecked exception.

Remember that catching and unchecked exception is the same as sweeping the problem under the rug.

When Jova throws an unchecked exception, like a right index out of bounds, that means there's something

wrong or there's something missing in your code.

So instead of catching the failure thickset so that it doesn't happen.

And there you go.

Now, the null pointer exception is thrown if you try to access something, if you try to dots and tags

from a null.

So inside one exception to that job, I try to call a method from the string class, I'm going to call

a random method like two lowercase.

And the code in line for fails and throws a null pointer exception, crashing the application, the

null pointer exception is an unchecked exception because it happens during the runtime and when you

get an unchecked exception, that means there's something wrong with your code.

Let's fix it.

So here I'm going to say if word is equal to null.

Then I'll print the word is no.

Otherwise, and only then are we allowed to call were lowercase.

So as you can see, the unchecked exception forced me to improve my code.

This was fully within my control.

And the reason this is being highlighted is because it's never going to run.

Word is always no.

So it's that code anyway is not too important.

But here's a common mistake.

Normally, you should always use the equals method to compare a string, but you can't use it to check

for a nail because dots and doxxing from a null trying to access something from a null is always going

to throw a nail pointer exception.

All right, let's fix it.

Never replace if with try catch.

I have no idea why people do this, if else statements are a lot faster than try catch and they're easier

to work with.

Besides only ever use, try and catch to catch the exceptions.

Now, the input mismatch exceptions thrown by scanner, if the user enters a value that it wasn't expecting.

So run the code inside runtime, except in three Java.

Skinner is expecting an integer, but we're going to pass in a string.

And we get an input mismatch exception, the input mismatch exception is an unchecked exception because

it was thrown during the runtime.

When you get an unchecked exception.

Then there's something wrong or there's something missing in your code.

In this case, what's missing is code that checks in advance if the next is an integer.

And only then are we going to pick up the values, scandal and extent.

Otherwise, we're going to have to pick it up using Scandi next line, because next line can pick up

anything.

And also, we'll tell the user.

Not a no.

OK, we on the code.

I'll put in a word, and just like that, we handled the unchecked exception by fixing our code.

Now we can say the code is reliable because there's no way that it's going to crash no matter what I

throw at it.

All right, we can actually take this a step further, we can use a while loop that runs forever.

If the next input is an integer, then we'll print it and break the loop.

And if the next input is anything else, then we'll pick it up with next line.

And now the code is going to keep asking the user to enter a number until they do.

If you can take anything away from this lesson, take this rule of thumb, catch a exception because

it's outside the applications control, in any case, Judge is going to force you to catch it before

compiling thickset, unchecked exception because it implies that there's something wrong or there's

something missing in your code.

In this lesson, you fixed three unchecked exceptions, an unchecked exception is a one time exception.

The failure happens during the runtime because of poorly written code and never catch an unchecked exception.

Instead, fix the code or improve the code so that the failure doesn't happen.