Exception Handling in Java is just the same as it is in real life. Let’s say you are driving from Princeton to New York.
2.Can you do anything to avoid break failure.
3.Can you do anything if an earth quake occurs on your way to New York ?
These are the three kinds of situation you come across in any program.
Exception handling in Java
So, How do we handle exceptions ? How do you program your code with good exception handling ? This is the question that comes to any one’s mind who has just learned OOPS concepts in Java and is looking to learn more.
Exceptions are kind of thrown when they occur. If you catch them and and do something about it, the program continues smoothly with what it was doing. If you don’t catch them, the program breaks and stops and you see red lines in the output. So, why would you not catch any exception ? Why would you allow it to break and stop a program. The reason is that there are kinds of exceptions that you are not supposed to catch. Confusing, right ? Read on….
There are two types of exceptions: Checked Exception and Unchecked Exception. In other words, Compile time Exception and Runtime Exception. Yes, I am giving the other terminology because otherwise you will tell me that you have heard of them and what they are. There is double terminology for almost everything in Java. This makes Java look difficult, when it’s not. You might still be feeling that Java is difficult, but never mind; let’s continue on with Exception handling, so that I can show you that Exception Handling is easy.
Checked and Unchecked Exceptions
The only two types of exceptions in Java are Checked and Unchecked. There is a class in Java called Exception, whose parent class(super class) is called Throwable. Throwable has two children, Exception and Error. Both Exceptions and Errors can be thrown literally. This is because they are children of Throwable and inherit that quality from it. We will talk about Errors later. We will continue on with Exceptions. Class Exception has a lot of children classes(subclass).
Exceptions are of two types, Checked and Unchecked Exception. So, how do you know which are checked and which are unchecked? Class Exception has a child class called Runtime Exception. All its children and their children and so on… are Unchecked Exceptions. All the brothers/sisters of Runtime Exception and their families under them are Checked Exceptions. In other words, all the children(and families under them) of Exception class, except Runtime Exception, are Checked Exceptions. They are called Checked because compiler checks for them and forces you to decide on weather you want to catch and handle it or not (allow it to break and stop your program).
Example FileNotFoundException. Unchecked exceptions should never happen if handled, so the compiler does not force you to decide on its handling. If you find an unchecked exception during testing you are supposed to fix your program so that an unchecked exception never occurs. For example, the NullPointerException is like break failure. So when you find that the break has failed during testing, go and fix it. You don’t handle a break failure when it happens while running the Car. It should be fixed when found, so that it never happens upon driving.
Errors are like an earthquake; they happen due to a problem in JVM or the physical machine. If they occur, they occur. You cannot do anything about them, except report them to the JVM creator or System Administrator.
Exception Handling For Checked Exceptions, the compiler will force you to do one of the two things. Either do a try catch finally or mention the throws clause at the end of the method signature. You have to fix unchecked exceptions so that they never occur. You cannot do anything about the errors; the error will be displayed on the screen when the program fails due to a JVM problem or machine problem.