Hi my doubt is on checked ,unchecked exceptions in java.
1)You know that if there is any possibility for checked exception to be thrown from a method and we do not have intention to handle the thrown exception
then we have to declare that exception in method header.
That means we have to write “throws EXCEPTION NAME” in method header.
2)But in case of unchecked exception, if there is any possibility for unchecked exception to be thrown from a method
then we do not declare that exception in method header..
That means we do not write “throws EXCEPTION NAME” in method header .
3)Why should we declare the exception in method header in case of checked exceptions ? what benefits are we getting by declaring exception in method header?
4)Why do not we declare the exception in method header in case of unchecked exceptions?
Checked exceptions are things that can be expected to go wrong even in an app with no bugs. A disk might fill up, a user might enter letters where he's supposed to enter a number, a network connection may drop. When that happens, the caller of the method performing that action should be notified of exactly what went wrong, so he can decide how to handle it, or if he should just pass it up in turn to his caller. Therefore, a method declares which of these kinds of things can go wrong by its throws clause.
Unchecked exceptions indicate things that you don't expect to go wrong, and that you generally can't or shouldn't have to deal with. If I call a method, and it throws NullPointerException, that's either a bug in that method, or a bug in my code that called it. Either way, there's usually no point in catching and handling that exception. Or maybe the JVM runs out of memory and we get an OutOfMemoryError. Again, there's usually nothing we can do about this. Since these exceptions can occur anywhere, and since there's usually no point in trying to handle them, it's not necessary to declare them.
Two additional points:
1) You'll notice I say there's usually no point in handling unchecked exceptions. Sometimes at major architectural boundaries we do handle them. For instance, a NullPointerException that my web app throws may bubble all the way up to the app container (tomcat, jboss, etc.). That container will catch my NPE, log it, and let my app die, but by catching it, it prevents my app from killing the whole JVM and killing other apps in the container.
2) There's a fairly large movement in the Java world against checked exceptions, and some languages have ONLY unchecked exceptions. (C#, for example, I think.) The reasoning as I understand it is that there's a LOT of code written to just catch, wrap, and rethrow checked exceptions, or even just to declare them, and very little work is done by this code. It's a lot of clutter to say, "I'm not going to deal with it, YOU deal with it." Personally I'm on the fence about it. I don't have a strong conviction either way, but a lot of people do feel very strongly about it. There's no single right or wrong approach. There was a reason the distinction was made when the language was first designed, and there are also reasons to go the other direction.
Jeff Verdegan wrote:2) There's a fairly large movement in the Java world against checked exceptions, and some languages have ONLY unchecked exceptions. (C#, for example, I think.)
I think Java is just about the only major language that does have checked exceptions. C++ had an optional exception checking mechanism that is now deprecated. OCaml, CLU and Modula-3 had similar features, sorta. Has anyone else here ever used a language besides Java that had checked exceptions?
I would also add:
3) Point (2) affects point (1) as well: if you're using a library that does not use checked exceptions, only unchecked, then you may well find it's appropriate to catch those unchecked exceptions at whatever level you find necessary. This shows up a lot if you use tools like Hibernate or Spring - but it's also present in some standard Java libraries. E.g. if you use Integer.parseInt(), it can throw a NumberFormatException, which is a RuntimeException. It is perfectly acceptable to catch this sort of exception at whatever lever you can do something useful about it, e.g. to inform the user that they have malformed input. It's not just for "major architectural boundaries".
1) Checked Exceptions are identified by Java Compiler at the compilation time, And it never compiles the Java files until and unless the exceptions are handled or thrown.
2) Unchecked Exceptions are Runtime Exceptions and are not identified by the java compiler (Java Compiler never bother about Unchecked Exceptions). JVM throws these exceptions at runtime. Example:- Array Index Out Of Bounds Exception, When you try to access the elements beyond the max size of the Array.
See the last line saying "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."
James Peterson wrote:See the last line saying "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."
The only problem with that is that you often run into code that doesn't follow that ethos...
shankara me wrote:1)You know that if there is any possibility for checked exception to be thrown from a method and we do not have intention to handle the thrown exception
...and two common cases of this are IOException and SQLException.
It's actually quite rare that you can actually "handle" either of those, since they're so generic; but the fact is: they're checked, so your code MUST acknowledge them.
Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
An example of an error which can be difficult to recover from is NumberFormatException.
It is usually bad practice for any method to throw and catch the same Exception. So the location where the Exception occurs usually throws it back down the call stack.
Joined: Mar 05, 2008
Campbell Ritchie wrote:An example of an error which can be difficult to recover from is NumberFormatException.
Curious, since I cited it above as an example that often can be quite easily caught and dealt with. If a user enters bad data, do you crash the whole application, or do you ask the user to fix it? I guess one can imagine examples where either option is valid.
Joined: Oct 13, 2005
Odd that MS and I said the opposite thing, but I think we agree with each other.
As Rob pointed out to me ages ago, now Scanner is available, you can use that. Following his suggestions I wrote myself a utility class, and it goes something like this:-The nice thing is that you don’t have to catch any Exceptions; that technique can ensure there never are any Exceptions. It might go into an infinite loop, however. You can recover from a NumberFormatException by putting the reading code in a similar loop if the user can re‑enter the input; that is quite easy.
If you are reading from a file, however, it is a moot point whether you can continue reading or crash or go into an infinite loop when you encounter such an Exception. If you expect a number and find something else, it may signify that the file is corrupt, or the wrong file. Then recovery from the Exception is probably worse than crashing.
Joined: Oct 13, 2005
Would a Scanner go into an infinite loop like that, or would it suffer an end of file exception? I shall have to try it some time.
Joined: Oct 13, 2005
I tried it. You suffer a no such element exception.