But We can predict that JVM error is possible.or lack of memory is possible,It is possible out of range of an array or�.
A checked exception tends to be something unusual but predicatable,
You are not required to list any unchecked exceptions you might throw in the method signature. And when you call a method that might throw an unchecked the compiler won't see any "throws" clause, and won't force you to catch or handle the unchecked exception. For example, lots of methods might throw NullPointerException. You can catch them or not, the compiler won't care
If your method, or any method it calls, can throw a checked exception, then your method must either catch that exception, or declare that your method throws that exception. This way, when I call your method, I know at compile time what can possibly go wrong and I can decide whether to handle it or just bubble it up to my caller. Catching a given exception also catches all that exception's descendants. Declaring that you throw a given exception means that you might throw that exception or any of its descendants.
If you have more objects than there is space for them, the program will crash. If you have a class missing, the program cannot run
Runtime Exceptions are called that because they occur entirely inside the Java runtime. Most (not quite all) runtime exceptions are (as Greg Buela has told you) the result of programming mistakes. Examples:-
The correct response to any of those is to go back where they happen and find out whether there is a programming error.
There are, however, a few runtime exceptions where the correct response might be to repeat the input, eg
These are probably worth catching.
Thrown by a Scanner to indicate that the token retrieved does not match the pattern for the expected type, or that the token is out of range for the expected type.
An attempt was made to use a class, variable, or method which is not available to the calling class.
Other Exceptions occur at some sort of interface between the Java runtime and something else, or somewhere else. So an IOException might occur between the JVM and the operating system
You declare that a method throws an exception if the problem can't be handled in the method. You handle the exception in the method if you can handle the error and continue with the method.
checked exception is it will be checked at the compile time .but unchecked exception is it only checked run time.
If an exception is always handled using the throws clause, then eventually the exception will propagate all the way back to the main method of the application. If the main method throws the exception and the exception actually occurs while the program is running, then the program will crash.
Originally posted by abalfazl hossein:
...If the main method throws the exception and the exception actually occurs while the program is running, then the program will crash?!Why?