Originally posted by kiru vembai:
Whatz difference between throws and try/Catch???
What are all exceptions(checked and unchecked) can be specified in Throws clause...?
And I need a clear idea about checked and unchecked exception and what type of exception can be handled by JVM?
Explanation to these would highly appreciated...
Howdy
This is way too big and important a topic for a little explanation here... but I'll give you a very quick overview, just to have at least *some* answer here:
1) a method can THROW an exception when something goes wrong. An exception is just a Java object, like any other Java object, except it inherits from Exception (which IS-A Throwable).
Errors (as opposed to Exceptions) are also Throwables, but I won't talk about Errors because they are NOT something
you should normally try to deal with, and they do not need to be declared. In other words, if an Error occurs (like an OutOfMemoryError) things are usually SO bad, that there isn't anything you can do anyway... what would you do if you *caught* a VirtualMachineError?? No, catching or trying to deal with Errors is only for the extremely advanced, and even then there is rarely a guarantee that you can do anything about them, so we'll ignore those).
2) the exceptions a method can THROW are either *checked* or *unchecked*
The *thing* doing the checking, for checked exceptions, is the compiler.
3) If a method might throw a *checked* exception, it MUST declare this by using the THROWS clause (public void go() throws GoException { }
4) A method is a *checked* exception if it IS-A java.lang.Exception but NOT a subclass of java.lang.RuntimeException. In other words, subclasses of RuntimeException are considered *unchecked*. For this reason, some people refer to *unchecked* exceptions as *runtime* exceptions. If you hear *runtime exception* or *unchecked exception*, most of the time people are talking about the same thing.
5) If you CALL a method with a THROWS clause, and the declared exception is a *checked* exception (a method can declare that it throws an *unchecked* exception, but the rules don't apply), then your method MUST follow the "Handle or Declare law".
6) Handle or Declare law means that if your method calls a method that declares a checked exception, you MUST either HANDLE the exception with a try/catch, OR you must declare that your method ALSO might throw that same exception.
7) HANDLE, means you must wrap the method call (in other words, the call to the method that declares a checked exception) in a try/catch block:
try {
callRiskyMethod();
} catch (DeclaredException ex) {
// do something
}
8) DECLARE means that you have decided that YOUR method can't (or shouldn't) handle the exception, so you decide that someone ELSE should handle it. Someone ELSE really means "a method lower on the call stack". In other words, if you DECLARE that you throw an exception, rather than HANDLING it with a try/catch, then you are "ducking" the exception and letting someone else... someone who called YOUR method... worry about the exception.
9) Checked exceptions are for things that you, as a programmer, cannot anticipate no matter HOW good a programmer you are. Many/most of these are related to networking and I/O... because you just can't guarantee when you're developing code that the file will always be there or that the network will always be up. They are considered "checked" because the Java programming model wants the compiler to guarantee that you, the programmer, are ACKNOWLEDGING that, "Hey, this is a very risky thing to do... (like open a File), and something could go wrong. I am aware that this might not work, and I have code that can deal with the problem just in case things DO go wrong." the idea is that if a checked exception is thrown, you should have a chance to recover. Perhaps you will try a different server. Perhaps you will access a local version of the file rather than trying to connect to the network to get the most recent online version... or perhaps you just won't carry out this particular operation, but the program can still function. Obviously, not all checked exceptions are things for which the client can recover, but at least there is a chance.
10) Unchecked exceptions are often a reflection of incorrect programming. These are problems that you WANT to come up as exceptions when you are
testing and debugging. They include things like ArrayIndexOutOfBoundsException or NullPointerException. These are not things that should NOT be happening in the course of a normal functioning program.
Note: I have GREATLY oversimplified!! And you really need to see code. I think I need to make a campfire story for this
cheers,
Kathy
