In a tutorial I found that Unchecked Exception can\'t be handled by your code i.e. we can\'t use try/catch
block and the examples are exception
yes we can handle Runtime Exception, plz check below code
public class Demo {
static void m1() {
int a[]=new int [5];
try {
a[12]=2;
}catch(Exception e) {
}
}
public static void main(String[] args) {
m1();
try {
String s=null;
System.out.println(s.length());
}catch(Exception e) {
}
System.out.println("hello world");
}
}
All the unchecked exceptions can be treated in the same way as the checked ones - if you want, you can let them pass by declaring that the method throws
them:
public void m() throws RuntimeException {}
Or you can catch
them:
public void m() {
try {
// some code
} catch (RuntimeException re) {
// do something
}
}
It should be noticed, the class RuntimeException
acts as a catch-all for the unchecked exceptions (since all the unchecked exceptions extend from it), much in the same way that the Exception
class is the catch-all for checked exceptions.
As has been mentioned before, the only real difference is that for checked exceptions you have to handle them (by letting them pass or catching them) and the compiler will make sure of it - on the other hand, the handling of unchecked exceptions is optional.
It all boils down to the expected usage of each exception type - you're supposed do be able to recover from checked exceptions (or at least do something about them, when they occur), whilst for unchecked exceptions, there might not be a reasonable way to recover from them. This of course, is a bit subjective.
Yes you can handle the unchecked exception but not compulsory. Actually it depends on application developer. Below is the possible reason where i think required to handle even unchecked exception.
If your application is large where many developers are calling each other API. It is better to handle the unchecked exception otherwise at the end your program will crash which stop the other functionality. So even the simple NullPointerException can stop your program working.
Imagine you have one scheduler which processing the user data and which is in million size and for the bad data you only want to print the log not to stop working for other good data. In that case if you have not handle the exception one bad data can stop your program
An easy way to think about the difference is to think the checking refers to the compile. If an exception is a checked exception, the compiler will check that your code either throws the exception or handles it in a try/catch block at compile-time. For unchecked exceptions, the compiler won't do such a check. You can handle checked/unchecked exceptions the same way (with try/catch/throws), the difference just lies in the checks the compiler performs. This post has a decent example.
They can be handled, but you don't have to. If you don't handle them, they will propagate and climb up the calling methods stack, until one of them catches it. If none does, the program will crash.
Usually, the bottom line is that if a client can reasonably be expected to recover from an exception, then it should be a checked exception. If a client cannot do anything to recover from the exception, then it's ok to have it as an unchecked exception.
Also, checked exceptions are useful to document an API that you expect to be used by 3rd-parties. When they know your method can throw a specific exception, they will code accordingly and handle the case. If you only use unchecked exceptions, all bets are off.
A common pattern (some people don't like it, but in some cases it's ok when you know what you're doing) is to wrap thrown checked exceptions into unchecked ones.
try {
... code that can throw CheckedException ...
} catch (CheckedException oopsSomethingBadHappened) {
throw new RuntimeException("Something bad happened!", oopsSomethingBadHappened);
}
Yes, you can throw unchecked exceptions with throw
. And yes, you can catch unchecked exceptions in a catch
block.