Exception Question

[Chandra Bhatt]

01. class BadObjectException extends Exception {}
02. class BadIndexException extends IndexOutOfBoundsException {}
03. 
04. public class Test {
05. 
06.   public void doSomething() {}
07. 
08.   public void aMethod() {
09.     try {
10.       doSomething();
11.     }catch(BadIndexException be) {
12.       System.out.println("BadIndexException");
13.       throw new BadIndexException(){};
14.     }
15.   }
16. 
17.   public void anotherMethod() throws BadObjectException{
18.     try {
19.       doSomething();
20.     }catch(BadObjectException be) {
21.       System.out.println("BadObjectException");
22.     }
23.   }
24. 
25.   public static void main(String[] args) throws BadObjectException{
26.     Test t = new Test();
27.     t.aMethod();
28.     t.anotherMethod();
29.   }
30. }

Answer says:
The code in anotherMethod() does not compile!
Why! Guide me anybody!


Regards,
cmbhatt

[Keith Lynn]

If you have a try block with a corresponding catch block, and the parameter of that catch block is a checked exception, then you will get a compil-time error if there is not a line of code in the try block that could cause the exception.
[ April 10, 2007: Message edited by: Keith Lynn ]

[Meena R. Krishnan]

When an exception (esp. Checked Exception) is being caught the compiler checks to make sure it is indeed being thrown by the try block. In your sample, BadObjectException which is derived from Exception is being caught but not being thrown in the Try block. Since it is derived from Exception which is a broader category, it can be any exception checked or unchecked.

In the case of aMethod(), since it is catching a runtime Exception, which we don't need to, the compiler never bothers. But in the case of anotherMethod() the compiler expects that it be thrown in the Try block.

If you either add 'throws BadObjectException' to doSomething() method declaration OR add 'throw new BadObjectException();' to the try block then should compile fine.

[Chandra Bhatt]

Thanks Keith, and Krishnan!

If you catch the checked exception (any exception that is derived from the Exception class except those which have been derived from RuntimeException)
the try block of that catch must throw that exception otherwise compilation error.

This rule is applicable with Throwable too.

If you declare after throws clause of the method that it throws any checked exception, no problem to the compiler whether you throw that or not inside the method or even if you catch that exception too besides declaring (while feeling sleepy, nothing comes in the mind), no problem though.

Any unchecked exception is free from all the discussed bondage.


Am I correct! specially on Throwable issue. Did I miss any name when wrote
Throwable.

I remind Error also but that is unchecked.


Regards,
cmbhatt

[Stuart Ash]

Originally posted by Chandra Bhatt:
Thanks Keith, and Krishnan!


Any unchecked exception is free from all the discussed bondage.

Bondage lol

Indeed! "Man is born free and everywhere there are checked exceptions!!" >


Apologies to Rousseau.

[chintan ramavat]

Hello CM Bhatt

I think you needed to declare "THROWS" with amtehod()(first one), may be that causes compilation error. Since the method is throwing an exception but it is not declared so, ( if you have method jargon then caller needs to declare just in case called does not ) but in this method there's no caller so may be method(first one) which is being called has to declare whatever it throws..

what do you think ? i hope its somewhat cleared

- chintan

[Chandra Bhatt]

Hey Stuart,
You are true! But that is desired otherwise Human wont take time to be chaotic.

----------------------------------------------------------------------

Originally posted by chintan
I think you needed to declare "THROWS" with amtehod()(first one), may be that causes compilation error.

No chintan,
Actually the problem is with anotherMethod() because it catches
BadObjectException that IS-A Exception (checked exception).
But the try block does not throw the exception, so the compiler error.
the anotherMethod() should have like this:
(1)
void anotherMethod() {
doSomeThing();
}
or
(2)
void anotherMethod() throws BadObjectException {
doSomeThing();
}

But the second method anotherMethod()'s throws BadObjectException is irrelevant.

If you catch any checked exception, inside the try block there must be
some code that causes it to throw the exception that is caught in the catch block

This is not true when you declare the exception.


Thanks,
cmbhatt

[swarna dasa]

Quote from K&B

"Just because the method declares that it throws an exception doesn't mean it always will. It just tells the world that it might."

you can have a method

void throwException() throws java.io.IOException //checked exception
{}
Method declares it might throw an IOException but it doesn't have to.

but cannot have
void catchException() {
try {
} catch(java.io.IOException e) {} //Error: Compiler assumes that the statements above will throw an exception but there isn't anything throwing that exception
}
[ April 10, 2007: Message edited by: swarna dasa ]

[Keith Lynn]

Actually you can do that with Exception because all unchecked exceptions are subclasses of Exception.

[swarna dasa]

Oops...
Thanks for correcting me.... Didn't realize i used catch (Exception)
correct it to catch(IOException)

[Sanjay Singh]

Hello Chandra, here BadObjectException is subclass of RuntimeException, so compiler shouldn't complain for the second method - anotherMethod().

java.lang.Object
java.lang.Throwable
-java.lang.Exception
-java.lang.RuntimeException
-com.hp.hpl.jena.shared.JenaException
-com.hp.hpl.jena.assembler.exceptions.AssemblerException
-com.hp.hpl.jena.assembler.BadObjectException

I m confused here.
[ April 11, 2007: Message edited by: Sanjay Singh@ ]

[Chandra Bhatt]

Hello Chandra, here BadObjectException is subclass of RuntimeException, so compiler shouldn't complain for the second method - anotherMethod().

Hi Sanjay,
See the topmost post!
class BadObjectException extends Exception {}

Exception is not RuntimeException, instead RuntimeException extends Exception.

My findings,

Case 1:
try{
}catch(Throwable t) {
}

case 2:
try{
}catch(Error e) {
}

case 3:
try{
}catch(Exception e) {
}

In all three cases, no compilation error like unreachable catch (the exception is never thrown in the try block)

But if you catch subclass of Throwable or Exception, the try block must throw it otherwise compilation error.


Regards,
cmbhatt

[Chandra Bhatt]

By the way,
why throwing Throwable is not necessary if it is caught in the catch block but its subclass must be thrown in the try block if it is caught in the catch block.

class BadLookingException extends Thread{}
 
//Case 1 
try {
}catch(Throwable t){
}
 
//Case 2
try{
}catch(BadLookingException ble) {
}
 
//Case 3 
try{
}catch(Exception e){
}

This rule does not apply to the Exception class which is subclass of the Throwable class.
Case 2 causes compiler error.
Cas3 4 no problem (Exception is checked exception)



Regards,
cmbhatt

[John Mathew]

Braindump question delete.

answer is C; wat my doubt is that this shud not compile untill bad method declares that it throws an exception.

Can anyone explain this
[ April 18, 2007: Message edited by: Barry Gaunt ]

[Chandra Bhatt]

Hi John,


The handle or declare rule applies only to the subclasses of the Exception class except subclasses of the RuntimeException.

Be sure if you handle the Exception, your code come under no obligation to throw it. Exception class is universal, it can catch any exception checked or unchecked (subtype of RuntimeException).

              Throwable
                  |
                  |
                  |
              ____|_____
              |         | 
           Error     Exception
                             |
                          RuntimeException 

Regards,
cmbhatt

[Meena R. Krishnan]

hmmm...

This following works...(w/o the exception being thrown in the try block)
Sorry, Braindump question deleted (see above for original poster)

the following doesn't work (still no exception being thrown in the try block).
Sorry, Braindump question deleted (see above for original poster)
[/CODE]
The only difference being the 'Exception' in the first class has been replaced by 'TestException'. Any thoughts?

[ April 18, 2007: Message edited by: M Krishnan ]

[ April 18, 2007: Message edited by: Barry Gaunt ]
[ April 18, 2007: Message edited by: Barry Gaunt ]

[raj malhotra]

The only difference being the 'Exception' in the first class has been replaced by 'TestException'.

I think whenever we extend Exception it becomes checked exception.We dont have separate name in the exception hierarchy specifically for checked exception only so we have to depend on Exception for this.but for runtime exception we have superclass - RuntimeException.There is little bit ambiguity as Exception covers both checked & unchecked.

If i am not correct .please correct me!