Exception handling in run()

Question

Hi,
now here is the situation
one of my classes that i made ClassA calls a run method of ClassB
ClassB in its run method calls a local method throwMethod() that throws an exception
now i want this exception to goto ClassA but because run method doesnot say
"Throws Exception" it is giving me some problem.
here is a sample code of what i am trying to accomplish:
public ClassA{
public static void main(){
ClassB b = new ClassB();
try{
b.run();}
catch (Exception ex){
System.out.println("yay Exception caught from classB's methodThrow  "); //
}//main of classA
}//classA
publc ClassB implements Runnable{
run() throws exception //this is not valid as the run() in Runnable doesnot 
//throw any exceptions.
methodThrow();
}//run of classB
public void methodThrow() thorws Exception{
throws new Exception("Goto classA");
}//methodThrow
}//ClassBthis is what i am trying to do and its not letting me do this..
i just want to ask this if a run method cannot throw any exception how i am supposed to handle exception if i want to handle that exception in the class calling the run of this class... or is it that i can only handle exception inside the run itself (which i cannot as this is not what i want to do..)
OR how can i tell the ClassA (which calls the ClassB.run() ) that the run method didnt execute properly so that ClassA can handle that situation properly like : put a system.out.println("the class didnt run"); or something
i would really appreciate the help...

Answer 1

They are not part of a method signature, but they are
part of the interface's contract, normally shown
using @throws tags in the documentation. The JLS
doesn't cover contracts, only the language. There's
plenty of examples in the standard API where the
interface's contract documents that a specific
runtime exception is thrown under certain
circumstances. But the fact that an unchecked exception is not described in the documentation doesn't mean that an implementing method must not throw it. So throwing any unchecked exception can never break a contract IMO, unless the docs specifically state that the exception must not be thrown, or must only be thrown in certain circumstances.
For example, calling Iterator.next()
after Iterator.hasNext() returns false breaks the
contract of the Iterator interface, and causes a
runtime exception to be thrown, but has no impact on
the method signatures when overriding them. Right. Following up with that, let's say I have an Iterator that is iterating over some sort of stream (reading bytes or lines or something). If the stream is interrupted, it's appropriate to throw an exception even though such behavior is not documented in the Iterator interface, and you would not break a contract to throw an exception.
The contract of
Runnable is that it may be called and not create any
recoverable exceptions, or else it will kill the
calling thread. If there was a good reason for
requiring the client to handle the exception, that
reason won't magically go away if you change it so
the compiler won't complain about it.Right. I had to think about it, but I don't see any advantage to crashing the thread versus logging the exception and gracefully finishing execution. So one might as well handle the exception rather than rethrowing it, since there will be no one (other than the VM) there to catch it.