threads and uncaught exceptions

[Barkat Mardhani]

public class Test implements Runnable { 
public void throwException() throws Exception { 
throw new Exception();
} 
public void run() throws Exception { 
if (Thread.currentThread().getName() == "T333") { throwException(); }
while (true) { System.out.println("Running thread = "+ Thread.currentThread().getName()); }
}
public static void main(String args[]) throws Exception  { 
Thread t1 = new Thread(new Test());
t1.setName("T1"); 
Thread t2 = new Thread(new Test());
t2.setName("T22"); 
Thread t3 = new Thread(new Test());
t3.setName("T333"); 
t1.start(); 
t2.start(); 
t3.start(); 
} 
}

The above code complains that overridden run() does not declare the exception. Is there anyway we can have threads with declared (uncaught) exceptions?
[ August 27, 2003: Message edited by: Barkat Mardhani ]

[Jose Botella]

It is not possible. It would violate the Liskov Substitution principle.

[Barkat Mardhani]

Thanks Jose. Is there some link for more info on this. Is this by design or a shortcomming? On the face value you DO want to use Threads and uncaught checked exception... Do'nt you...

[Jose Botella]

Hi Barkat,
from JLS

8.4.6.3 Requirements in Overriding and Hiding
If a method declaration overrides or hides the declaration of another method, then a compile-time error occurs if they have different return types or if one has a return type and the other is void. Moreover, a method declaration must not have a throws clause that conflicts (�8.4.4) with that of any method that it overrides or hides; otherwise, a compile-time error occurs.
In these respects, overriding of methods differs from hiding of fields (�8.3), for it is permissible for a field to hide a field of another type.
The access modifier (�6.6) of an overriding or hiding method must provide at least as much access as the overridden or hidden method, or a compile-time error occurs. In more detail:
* If the overridden or hidden method is public, then the overriding or hiding method must be public; otherwise, a compile-time error occurs.
* If the overridden or hidden method is protected, then the overriding or hiding method must be protected or public; otherwise, a compile-time error occurs.
* If the overridden or hidden method has default (package) access, then the overriding or hiding method must not be private; otherwise, a compile-time error occurs.
Note that a private method cannot be hidden or overridden in the technical sense of those terms. This means that a subclass can declare a method with the same signature as a private method in one of its superclasses, and there is no requirement that the return type or throws clause of such a method bear any relationship to those of the private method in the superclass.

[Jose Botella]

and from JLS 8.4.4:

A method that overrides or hides another method (�8.4.6), including methods that implement abstract methods defined in interfaces, may not be declared to throw more checked exceptions than the overridden or hidden method.
More precisely, suppose that B is a class or interface, and A is a superclass or superinterface of B, and a method declaration n in B overrides or hides a method declaration m in A. If n has a throws clause that mentions any checked exception types, then m must have a throws clause, and for every checked exception type listed in the throws clause of n, that same exception class or one of its superclasses must occur in the throws clause of m; otherwise, a compile-time error occurs.

[nowait shen]

why not make run throw "RuntimeException?"
replace all Exception to RuntimeException, and the code will compile

[Barkat Mardhani]

The RuntimeException will take care of run time exceptions. But one can not declare any checked exceptions because there is none mentioned in overridden run method signature.
Jose: I understand the restriction. But what I do not understand is rationale behind. The restriction enforces that all checked exceptions should be caught programmatically for a newly established thread (except main thread). This means that if it is required to bubble up the checked exception, it is not possible and program can NOT be stopped in exceptional conditions. Am I getting it right?
Thanks
Barkat

[Marlene Miller]

I searched The Java Programming Language and Concurrent Programming In Java for clues on rationale. Here are some related ideas.
Exceptions always occur in a specific thread, due to the actions of that thread.
Calls, callbacks, or notifications to error-handling objects can be used when an exception in one thread requires compensating actions in other threads.
When a normally recoverable error cannot be dealt with, you can force extreme responses by escalating it to a throw of a RuntimeException or Error or System.exit.

[Karl Harbour]

The design rationale for the run() method not throwing exceptions is because there is no calling context that could handle the exception.
Put another way, where in class Test could you put a try/catch block that would catch the exceptions thrown by run(), given that the run() method is never invoked by Test? From the programmer's perspective, run() is invoked as if by magic.
What you have to do in this situation is implement a producer/consumer type pattern, where the thread calls back to its creator to report its completion status.

[Marlene Miller]

from the Java Programming Language,
Exceptions always occur in a specific thread, due to the actions of that thread--for example, trying to perform division by zero, or explicitly throwing an exception. Such exceptions are synchronous exceptions and always remain within the thread.
...If the exception is not caught by the time the run method completes abruptly then it is, by definition, an uncaught exception. At that point the thread that experienced the exception has terminated and the exception no longer exists.
----
This link is not directly related to the current topic: The Trouble With Checked Exceptions

[Barkat Mardhani]

Thanks Guys.