Checked Exceptions are very different from Unchecked Exceptions. As a programmer, you are considered "accountable" for handling checked exceptions appropriately. In the first case, you're trying to catch a checked exception that can never be thrown. This cuases an error. Unchecked exceptions (as the name implies), go unchecked by the compiler. Exception and it's child RuntimeException are examples of unchecked exceptions. As the compiler doesn't know when or where an unchecked exception might be thrown (i.e. a NullPointException is an unchecked exception), it doesn't know that the code you have written is incapable of throwing such an exception. As checked exceptions must be thrown by the programmer, the compiler knows that the exception won't be thrown, obviously, this isn't possible with unchecked exceptions. Check out the JLS, §11.2 Compile-Time Checking of Exceptions, for more information. I hope that helps, Corey [ March 20, 2003: Message edited by: Corey McGlone ]
Thanks Corey. Exception could hold its subclasses of CheckedException too, so I guess its making provisions considering it might hold RuntimeException.
Joined: Dec 20, 2001
Originally posted by sun par: Thanks Corey. Exception could hold its subclasses of CheckedException too, so I guess its making provisions considering it might hold RuntimeException.
Right. Because catching a particular exception type will catch not only that exception but all child exceptions, it doesn't make sense to have Exception be a checked exception because you would then be requried to handle RuntimeExceptions as checked exceptions because RuntimeException is a child of Exception.
The mother of unchecked exceptions is RuntimeException. So actually, Exception is a checked exception. This code won't compile:
The reason catch (IOException e) cause the compile-time error and catch (Exception e) doesn't is probably due to the fact that Exception encompasses both checked and unchecked exceptions. When you just catch Exception, there is really no way that the compiler can determine for sure if it needs to enforce the implied "if you catch a checked exception, there should be code that can throw it" rule. If the programmer merely wanted to catch a RuntimeException, the compile-time error would not be appropriate. Because of this ambiguity, I always question code that catches Exception instead of more specific ones. Catching specific exceptions makes the code's intent much clearer and can help you avoid introducing hard-to-find bugs into code. [ March 20, 2003: Message edited by: Junilu Lacar ]
it causes compiler error because the code in the try block will never throw BlueException which you made a checked exception. but if you try to make BlueException extends RedException then the code will compile fine since as you define that the methd me may throw RedException then it could also throw BlueException as a subclass of RedException. but one moment convert the order of the two catch clauses ( catch blueException first or it'll not compile)
I not only use all the brains that I have, but all that I can borrow. [Laurence J. Peter]
Joined: Oct 03, 2002
This code compiles and runs without any problems where as BlueException,RedException causes compiler error. Why
Joined: Feb 13, 2003
when you catch Exception then you didn't determined that you want to catch checked exception specifically since runtime exception could also be caught by this catch clause and the compiler dosn't check in this case wheather the code inside the try clause could throw a runtime exception or not. there's a differnt case when you define that a method throws Exception then you could throw a checked exception (as a subclass of Exception )in the body of the method and this gives the compiler the responsibility to treat this method as it throws checked exception so it must be called inside try clause.