runtime exception & checked exception

JAVA 提供两种异常，检测与非检测；
检测异常类是java.lang.Exception and its subclass.
non checked exception is java.lang.RuntimeException,java.lang.Error and their subclass.

Checked exceptions indicate an exceptional condition from which a caller can conceivably recover.
Conversely, runtime exceptions indicate a programmatic error from which a caller cannot normally recover

As a rule of thumb, you should always catch a checked exception once you reach a point where your code can make a meaningful attempt at recovery.
However, it is best not to catch runtime exceptions. Instead, you should allow runtime exceptions to bubble up to where you can see them.

If you do catch runtime exceptions, you risk inadvertently hiding an exception you would have otherwise detected and fixed. As a result, catching runtime exceptions complicates unit
and regression testing. While testing, seeing a stack trace or allowing the test to catch and report runtime exceptions lets you quickly identify problems.
Some programmers advocate catching and logging runtime exceptions, but I disagree because that makes you read through logs while you unit test your code. A unit test should indicate
whether the test passed or failed without manual verification from a log. Let the unit test catch the exception, not the code being tested


Catching runtime exceptions also leads to a worse problem: what exceptions do you catch, and when do you catch them? Runtime exceptions are undeclared,
so how do you know what you should catch? How do you know there's an exception to catch? Certainly you wouldn't place try/catch blocks around every method call and array access you perform?