Java Tutorial - TRY CATCH for handling exceptions

Common Sense?
30 followers
9 Video Views·Oct 21, 2022
There are two broad categories of errors you can encounter in Java programming.
First of all, there are syntax errors. These are coding errors that you have to fix
before you can even compile your application. Let's take a look at this simple comment.
It starts with two slashes. If I were to forget to put in the second slash,
I would have a syntax error. The Java compiler won't recognize that. It doesn't know what
And when I try to run it, I'll get a compilation error shown here in the build window.
I'll just get rid of that bit of code completely, I'm not interested in it.
And instead, I'll show you a more common sort of problem.
Let's say I'm trying to create a string, and I want to assign it initially to a value of null.
If I don't put in my semicolon, that's a syntax error.
And again, I can't even compile the application.
Those are the most obvious kinds of errors that you'll see in your Java code.
They're pretty easy to track down, because you always get an error listing that shows
you exactly where the error is, and some sort of description of the mistake that's been made.
The more complex problem, though, are exceptions.
An exception is an error that occurs while the app is running.
Let's take this string again. It's a null object.
That means I don't have access to any of the object's members, properties, or methods.
If I were to say, create a variable named sub,
and I'll get that value from a substring starting at position 1,
and then I try to run that code, I'm going to crash the application.
And I'll get a special kind of exception called a null pointer exception.
It's telling me I can't get to the substring method,
which is supposed to be a member of the sub object, because the sub object doesn't exist.
It's null.
So, how can you handle these kinds of exceptions?
The answer is through a construct called try-catch.
IntelliJ IDEA makes it very easy to add a try-catch block around a bit of code.
Select the code that's causing the issue, then go to the menu and choose code,
surround with, and choose try-catch.
The code you selected will end up in the try block, and a catch block will be added after it.
Here's how you can translate a try-catch block.
I'll try to execute the code in the first block.
If that code succeeds, the flow of execution will jump past the catch block, and I'll be down here.
And I'll indicate that I'm down here by outputting a string of, I'm not dead yet.
If I run the code now, I'll see that I'm still getting the null pointer exception,
but I'm handling it, and so the application can continue running.
When you execute the catch block, you have a reference to an exception object.
The type of the exception object is important.
The type, by default, is simply exception.
I'll click into that class and press Shift-F1, and go to the documentation.
Notice that the exception class has a whole bunch of different subclasses.
The exception class is at the top of an inheritance hierarchy.
Every one of these subclasses, these child exception classes,
inherits everything that the exception class does.
They have all the same methods, constructors, fields, and so on.
And so, that's why we're able to call this method printStackTrace.
That means, tell me everything you know about the nature of this exception,
and dump that information into the console.
So I run the code again, and all this output right here
is being caused by the call to printStackTrace.
But because I caught the exception, the application can continue running.
The try-catch construct is critical to handling exceptions in Java.
You can add code that you know might cause a problem within a try block,
and then you can catch and handle the exception in the catch block,
and then you can let the application keep on doing its thing.
When you start working with structured exception handling,
you quickly discover that not all exceptions are equal.
The exception class is the superclass for a whole bunch of different kinds of exceptions.
And when you trigger an exception,
you can find out very quickly what kind of exception you got.
In this starting code, I'm going to encounter a null pointer exception.
That's because I have an object that I've set as null,
and then I'm trying to access one of its members that doesn't exist.
And so when I run this code, I hit this catch block,
and I see the result of this printStackTrace call.
Because I handled the exception, this code survives,
and I get to the last executable line.
But you can use a structure called multi-catch,
where you have distinct catch blocks for each different kind of exception.
Let's say, for example, that in this catch block,
you wanted to make it specific to null pointers.
In addition to outputting the stack,
I'll do an explicit bit of output that says null pointer,
and then I'll append to that the message associated with the exception.
And the expression for that is e.getMessage.
I'll run the code,
and I'll see that once again I successfully survived the exception
and run all of the code to the end.
Now I'm going to change the nature of the exception.
Instead of setting the string to null, I'll set it to an empty string.
Now when I call the substring method,
I'll get an indexOutOfBoundsException.
I'll run that code,
and I'll see my stack trace,
but now I don't survive to the end of the code.
I don't get to this last line.
I don't have code to catch that particular kind of exception.
So I'll add that here.
I'll add a new catch block,
and this will be specifically for StringIndexOutOfBoundsException.
As before, I'll create the variable with the name of e.
I'll take this bit of code and copy it.
Paste it here.
I'll change this label to OutOfBounds,
and now when I run the code, I get my OutOfBoundsException,
and I also get to the end of the code,
because now I'm handling both kinds of exceptions.
If you want to absolutely guarantee that you handle all exceptions,
you can add another catch block
and go back to handling exception here.
I'll paste that code in again,
and I'll change this label to I Don't Know What Happened.
When I run the code, I get the StringIndexException,
and because I handled it, I survived to the end.
This final catch block is only there
to handle any exceptions I didn't anticipate.
So that's a multi-catch architecture.
You can have as many catch blocks as you need
for the different kinds of exceptions you might need to handle.
