aspose file tools*
The moose likes Java in General and the fly likes exception handling Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "exception handling" Watch "exception handling" New topic
Author

exception handling

shankara me
Greenhorn

Joined: Nov 30, 2012
Posts: 14
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?
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

The basic philosophy is this:

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.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3011
    
  10
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".
venkat mvr
Greenhorn

Joined: Mar 01, 2013
Posts: 1
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.
James X Peterson
Whizlabs Java Support
Ranch Hand

Joined: Feb 26, 2013
Posts: 158
Hi,


I think following link will help you.

http://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html


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."


Regards,
James
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7676
    
  19

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.

Winston

Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38405
    
  23
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.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3011
    
  10
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.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38405
    
  23
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.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38405
    
  23
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.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38405
    
  23
I tried it. You suffer a no such element exception.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: exception handling