This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
Up until recently I have been studying for the Programmer Exam, and in one of the examples I wrote I came across an inconsistency. I am aware that static methods are hidden in a derived class instead of overridden and that the method is bound at compile time. I have also picked up that the checked exception rule applies to hidden methods (ie if an exception is thrown it must be a subclass of the exception thrown on the parent method), so I was little surprised when I received the following compiler message for the code below: ... the code ...
... the error ...
In particular that it is referring to my method as overridden when it is hidden! Is this a little bug in JDK, or did I miss something along the way? A more general question: Why does Java force the checked exception rule to hidden methods, given that polymorphism doesn’t apply? . Ie normally (on a non-static method) the check is in place to prevent a subclass raising an error in its overridden method definition that can not be handled by the code referencing the parent class. In the event of a non-static method, it is bound at compile time and therefore no surprises in store at run time so I can’t see the need for the rule. Regards, Matt
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.
This is to insure that the methods are "type-safe". Imagine that you have a variable declared as the type of the parent. Any object sitting in the variable must be able to respond to any calls to the methods of the parent class. So if there is an object of the sub-class in this variable and the variable is used to invoke the static method that it is using to hide the parents static method, and SUDDENLY the sub-class throws an exception that the "type" of the variable does not know about - well that is the makings of disaster. Actually the mechanics of this are described in the JVM Spec. From 3.10 Exceptions
The order in which the exception handlers of a method are searched for a match is important. Within a class file the exception handlers for each method are stored in a table (�4.7.3). At run time, when an exception is thrown, the Java virtual machine searches the exception handlers of the current method in the order that they appear in the corresponding exception handler table in the class file, starting from the beginning of that table. Because try statements are structured, a compiler for the Java programming language can always order the entries of the exception handler table such that, for any thrown exception and any program counter value in that method, the first exception handler that matches the thrown exception corresponds to the innermost matching catch or finally clause. Note that the Java virtual machine does not enforce nesting of or any ordering of the exception table entries of a method (�4.9.5). The exception handling semantics of the Java programming language are implemented only through cooperation with the compiler. When class files are generated by some other means, the defined search procedure ensures that all Java virtual machines will behave consistently.
Notice that the classfile that is searched is the classfile for the TYPE of the variable not the class of the object.
PS: The message is from the compiler - not the JVM. They probably just use the same message for both overridden and hidden cases. [ April 10, 2002: Message edited by: Cindy Glass ]
"JavaRanch, where the deer and the Certified play" - David O'Meara