why we should not catch unchecked exceptions?

[kiran madhan]

i read somewhere...we should not catch unchecked exceptions....? why...?  i can throw ArithmeticException...and i can catch it...just like IOException, which is Checked exception.....? what is the difference....? Can anybody help me please..?

[praveen kumaar]

Hi Kiran!

As you know checked exceptions are one which can be caught during compiling your code and can be handled  at the compiler level.but in case of unchecked exception compiler don't checks it when it compiles your code means you can leave it.

Handling a Exceptions means you know about how and when that exceptional situation may arise so you handle them.
now for ex:-RuntimeException do you really think you can handle them it means you know about the situation when it arises so why don't you remove that error
instead of handling it.one can not predict when this exception may arise because their are not predictable(may arise due to several reasons like outofmemory,illegalstate...etc).

Hope This will help!

kind Regards!
praveen.

[praveen kumaar]

you should read this oracle tutorial where they explain the such controversies.
read it carefully.

[kiran madhan]

praveen kumaar wrote:Hi Kiran!

As you know checked exceptions are one which can be caught during compiling your code and can be handled  at the compiler level.but in case of unchecked exception compiler don't checks it when it compiles your code means you can leave it.

Handling a Exceptions means you know about how and when that exceptional situation may arise so you handle them.
now for ex:-RuntimeException do you really think you can handle them it means you know about the situation when it arises so why don't you remove that error
instead of handling it.one can not predict when this exception may arise because their are not predictable(may arise due to several reasons like outofmemory,illegalstate...etc).

Hope This will help!

kind Regards!
praveen.

Thanks a lot praveen...! What i understand is checked exception is the one which we may not predict....but compiler predicts it....to handle...!
whereas, unchecked exception is the one which we can find it and handle it...! but without running my code how i know it should be a checked exception or unchecked exception...?

[Junilu Lacar]

praveen kumaar wrote:
As you know checked exceptions are one which can be caught during compiling your code and can be handled  at the compiler level.but in case of unchecked exception compiler don't checks it when it compiles your code means you can leave it.

As worded, this is incorrect. Exceptions, both checked and unchecked, can only be caught at runtime because that's the only time they will ever get thrown. Program code is never executed when it is compiled. However, code can be analyzed at compile time and the compiler can check it for compliance with the rule that code from which a checked exception can be thrown must either handle the exception with a catch block or declare the exception in a throws clause in that code's method header. That rule does not apply to code that can throw an unchecked exception.

Many programmers and designers find checked exceptions onerous though, so there's a fairly common practice to use unchecked exceptions even in situations where you can expect to encounter an exception from which you can gracefully recover. This approach is less cumbersome but it also requires a little more discipline and thoughtful design because then, developers/designers will get no help from the compiler. They will have to exercise due diligence to ensure that the exception is properly dealt with at some point along the execution path. The designers of the Spring framework favor unchecked exceptions over checked exceptions.

The advice to not catch unchecked exceptions is usually made when advocating for intensive unit testing. The assumption is that rigorous testing will cause these unchecked exceptions to be thrown and cause test failures. The test failures will force the programmers to find the root cause of the problem, which is usually a programming error, during development and fix the code so that there is no possibility of that exception occurring in the production environment.

[kiran madhan]

Junilu Lacar wrote:

praveen kumaar wrote:
As you know checked exceptions are one which can be caught during compiling your code and can be handled  at the compiler level.but in case of unchecked exception compiler don't checks it when it compiles your code means you can leave it.

As worded, this is incorrect. Exceptions, both checked and unchecked, can only be caught at runtime because that's the only time they will ever get thrown. Program code is never executed when it is compiled. However, code can be analyzed at compile time and the compiler can check it for compliance with the rule that code from which a checked exception can be thrown must either handle the exception with a catch block or declare the exception in a throws clause in that code's method header. That rule does not apply to code that can throw an unchecked exception.

Many programmers and designers find checked exceptions onerous though, so there's a fairly common practice to use unchecked exceptions even in situations where you can expect to encounter an exception from which you can gracefully recover. This approach is less cumbersome but it also requires a little more discipline and thoughtful design because then, developers/designers will get no help from the compiler. They will have to exercise due diligence to ensure that the exception is properly dealt with at some point along the execution path. The designers of the Spring framework favor unchecked exceptions over checked exceptions.

The advice to not catch unchecked exceptions is usually made when advocating for intensive unit testing. The assumption is that rigorous testing will cause these unchecked exceptions to be thrown and cause test failures. The test failures will force the programmers to find the root cause of the problem, which is usually a programming error, during development and fix the code so that there is no possibility of that exception occurring in the production environment.

it cleared all my doubts....thanks a lot..! and i have read praveen oracle link...and this overall explanation gave full pack of answer....thanks

Junilu Lacar

[Junilu Lacar]

For future reference, please quote only the parts of a post that are relevant to your response. Please avoid quoting the entire post, especially if it's long like mine tend to be.

[praveen kumaar]

Thanks for the information junilu.
i intended to say they can be checked at compile time that programmer had made some strategy or not if it arises during during runtime,either by handling it or throwing it to the implementation code.
now come to unchecked exception(named well).as the compiler analyzes the code and also performs some basic logic checks like whether the statement is reachable or not.but their are things like Arithematic logic check(Number divided by zero..etc...),index related issues ,null refrence used-they all are checked during runtime if JVM founds any type of issues with them then it throws a RuntimeException or its sub class.but Since Runtime exceptions had numerous of issues related with it which are quite unpredictable so better will be to not handle them.
if we handle them abruptly maybe we are not able to caught the original source because after handling it will not be propogated over stack resulting in incomplete information of why actually program stops.
so i would better call it is a bad practice to handle RuntimeException instead of calling it is bad practice to handle Unchecked Exception.

sometimes handling a unchecked exception which a programmer can predict is a good idea.

@junilu Is it right now?
correct me if i am wrong.

Thankyou

Kind Regards,
Praveen.

[praveen kumaar]

@Kiran Checked exception extends a Exception class and unchecked exception extends a RuntimeException class,you can use the same logic for diffrentiate the 2 types and this is also the only way to create such type of Exceptions.

Thanks!

Kind Regards,
Praveen.

[Junilu Lacar]

praveen kumaar wrote:
so i would better call it is a bad practice to handle RuntimeException instead of calling it is bad practice to handle Unchecked Exception.

sometimes handling a unchecked exception which a programmer can predict is a good idea.

Honestly, it's a little challenging to parse what you're trying to say in your responses. We understand that English is not everyone's primary language so we try not to hold it against anyone if they don't have a full command of English grammar and punctuation but your posts quite frankly look like you're writing them on a cell phone that doesn't have a full QWERTY keyboard. Don't get me wrong, we do very much appreciate the effort you put into trying to help. I would just ask that you be a bit more liberal with spaces between words and after full stops and other punctuation marks as appropriate.

As for what you wrote that I have quoted above, RuntimeException and "unchecked exception" are interchangeable terms; they basically are the same thing so it really doesn't make sense to say that handling one is better or worse than handling the other.

Programmers should properly handle unchecked exceptions when they are expected and are not caused by programming errors.

Standard RuntimeExceptions like NullPointerException and ArrayIndexOutOfBoundsException should NOT be handled explicitly in the code but treated as a symptom of some programming error(s) that need to be tracked down and fixed before going to production.

[praveen kumaar]

I will try my best junilu.
Actually whenever i post here,either for asking something or helping someone,helps me to learn several things like How to speak better English or other specific thing by interacting with people here on ranch.so,in meantime of course i will learn it.and junilu i don't get you wrong,i am really thank full to you for your last post.

Actually what i meant to say is-
ArithmeticException and ClassCastException,they both are RuntimeException but not every RuntimeException is a ClassCastException or the other one.did you get my intention now.

Thanks again for your suggestion.

kind Regards,
Praveen.

[Daniel Cox]

Junilu Lacar wrote:Many programmers and designers find checked exceptions onerous though, so there's a fairly common practice to use unchecked exceptions even in situations where you can expect to encounter an exception from which you can gracefully recover.

I don't think that unchecked exceptions are used in situations where you can recover. From what I understand, Spring (unlike JDBC) uses unchecked exceptions for many database-related problems because you cannot recover from these problems.

The Java™ Tutorials wrote:If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.

[Junilu Lacar]

Daniel Cox wrote:
I don't think that unchecked exceptions are used in situations where you can recover. From what I understand, Spring (unlike JDBC) uses unchecked exceptions for many database-related problems because you cannot recover from these problems.

Spring wraps checked DB exceptions in unchecked exceptions. This makes extending framework classes easier because you don't have to deal with compiler errors caused by not handling/declaring things like SQLException. However, it also forces you to think about what you're going to do about those errors: do you just let it propagate up the call chain until it gets to a default, catch-all handler or do you handle them earlier on? SQLRecoverableException was introduced in Java 6, I supposed to cover situations where you could do something to recover.

The same strategy gets applied to other areas of the application, generally to avoid or get rid of all the duplicated log messages caused by naive programmers writing code that simply logs then rethrows an exception they don't know or take the time to know what to do with. There's an unwritten rule of thumb that many programmers follow to "at least log an exception before rethrowing it". When everybody does that and nobody actually sits down to think more carefully about the proper action to take, you'll see 5 or 6 duplicate log messages caused by one single exception that was log/rethrown every step of the way up the call stack on its way to the default, catch-all application exception handler. The problem is, the log message might not be consistent so it's not immediately obvious that they're duplicated. This becomes very troublesome when it happens a lot, and it often does when schedule pressure starts to make programmers take the easy way.

I suggest you look into more conversations around the pros and cons of unchecked vs checked. There was a lot of arguing and hand-wringing around that shift to unchecked exceptions when Spring first brought it to the fore.