• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

threads and uncaught exceptions

 
Ranch Hand
Posts: 787
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]
 
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It is not possible. It would violate the Liskov Substitution principle.
 
Barkat Mardhani
Ranch Hand
Posts: 787
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
why not make run throw "RuntimeException?"
replace all Exception to RuntimeException, and the code will compile
 
Barkat Mardhani
Ranch Hand
Posts: 787
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 787
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Guys.
 
reply
    Bookmark Topic Watch Topic
  • New Topic