Because, exceptions can be encountered at either compile time or run time.
1. some exceptions can be predicted i.e if you are going to read a file, there is every possibility that either file is not readable, you don't have privilege to read it, it doesn't exist etc. that's why this is checked or this code can be detected at run time that this exception can come.
2. If exception is dependent on your input, a program doesn't know if your app has some validation and you will never pass 5/0 to your api. So this remains unchecked unless you will give bad input.
All exceptions subclass of Exception is checked and RuntimeException is unchecked.
The difference between checked and unchecked exceptions also does not have anything to do with what can or cannot be determined at compile time or at runtime.
The reason why for example FileNotFoundException is a checked exception and not an unchecked exception is actually just a choice that was made by somebody who invented that exception long ago. There's no real technical reason why it could only be a checked exception.
The page that I linked to explains what the philosophy is. Checked exceptions are supposed to be used for conditions that the programmer can reasonably expect to happen, such as a file that can't be found. Unchecked exceptions are supposed to be used for conditions that should never happen, and that mean that there is probably a bug in the application.
Note that in practice, not everybody follows this philosophy. In particular, there are people who think that checked exceptions are unnecessary or even a bad idea, and that you should use unchecked exceptions for everything. Oracle's tutorial has some more information on that on the page Unchecked Exceptions — The Controversy.
harshvardhan ojha wrote:Because, exceptions can be encountered at either compile time or run time. . . . .
Nonsense. Exception only occur at runtime. “Determined at compile time or run time” is confusing, and probably wrong, too.
I suggest you start with the Java Tutorials. There are not two kinds of Exception; there are at least three. Checked Exceptions, unchecked Exceptions and Errors.
Errors are things which can go wrong with the JVM for which there is likely to be no chance of recovery. At least in theory.
Runtime Exception and its subclasses are things which go wrong entirely inside the runtime, and are regarded as being caused by mistakes in the code, which cannot be recovered by trying again. There are some classes which do not fulfil that description, e.g. NumberFormatException. To add to what Jesper said, RuntimeException is called that because it is something which happens entirely inside the runtime. Other Exceptions may occur at an interface between the runtime and other parts of the computer/network, or outside the runtime.
Checked Exceptions can in theory be recovered from by supplying more information and trying again. At least in theory.
You will find this is one of the features of Java which has engendered the most controversy.
Campbell Ritchie wrote: There are not two kinds of Exception; there are at least three. Checked Exceptions, unchecked Exceptions and Errors.
While that's true with the capitalization, that's just a special case of there being two types of exception (lower case "e")--checked and unchecked. From JLS (JSE 5 & 6) 11.2 Compile-Time Checking of Exceptions: "The unchecked exceptions classes are the class RuntimeException and its subclasses, and the class Error and its subclasses. All other exception classes are checked exception classes. ." Section 11.2.4 goes on to include Error in "unchecked exceptions."
The Java 7 JLS words it a bit differently, but still says the same thing.
Jesper de Jong wrote:In particular, there are people who think that checked exceptions are unnecessary or even a bad idea, and that you should use unchecked exceptions for everything.
And then, there are ornery types like me who think that having both types is good, but that the choices of making
(a) the type strictly hierarchical,
(b) certain vague "catch-all" exceptions, like IOException and SQLException checked,
were bad ones.
It's too late now, but personally I'd have made CheckedException a marker interface...
Bats fly at night, 'cause they aren't we. And if we tried, we'd hit a tree -- Ogden Nash (or should've been).
Articles by Winston can be found here
Joined: Oct 13, 2005
It all depends what you mean by three. Agree with WG that a marker interface would have been a good idea.