Rekha Srinath

Hi friends
I was a regular follower of JavaRanch a few months back. Due to work reasons, I had to break my preparation for SCJP 6 for a few months...

After a repeat effort during the past 2 months, I cleared SCJP 6 today with 91%...Yahooooooooooo :-)

My huge thanks to K&B for giving such a wonderful book..I never knew someone could make a technical book so interesting...My favourite topics were : Serialization (wherein each exception that could be caused was taken in a step-by-step manner and the method to solve it) and Threads chapter (Very interestingly covered in a sequential manner)

But, sometimes I get the feeling that the "Development" chapter could have been a bit more detailed. But that chapter could have been a cake-walk for experienced programmers with on-the-job Java coding practice :-)

Anyways, am glad that I passed SCJP with a good score...

Thanks to the Ranchers as well who cleared my doubts...

Ganesh

This problem is similar to your other post
https://coderanch.com/t/418092/java-programmer-SCJP/certification/checked-exception

Also, for the code you posted, I dont think the options are right with the code AS-IS...
I tried the following modified code... And with this code, options 2 and 4 are correct.

import java.io.*; import java.sql.*; public class test { public static void main(String[] args) throws Exception { m1(); } static void m1() throws Exception { try { //throw new IOException(); -- Comment-1 // m2(); -- Comment-2 } catch (IOException e) { throw new SQLException(); } /*catch(SQLException e) { throw new InstantiationException(); }*/ finally { throw new CloneNotSupportedException(); // this is not a //RuntimeException. } } static void m2() throws Exception {} }

Line marked Comment-1 : Uncomment this line alone, and comment out the catch(SQLException e) block... What happens is, IOException is thrown, catch (IOException e) is eligible to catch it, buy finally overrides the return with CloneNotSupportedException. Hence, CloneNotSupportedException is thrown at the end.

Line marked Comment-2 : Uncomment this line alone...This calls another function m2() that declares that it COULD throw an Exception but actually it does not ...
In this case, since no exception is thrown, no catch is run but finally runs thus throwing a CloneNotSupportedException.

I feel the options given are not suitable ones for the original code because there are compilation errors. Sorry, I didnt compile the code earlier.

I think your "line 1" is the m1() call in main.

Assuming so, if IOException is thrown, then the first catch clause is eligible to catch it, but there is a finally clause also with a return statement. If there is a return statement in finally clause, then any other return is neglected...ie. the finally takes precedence and finally's return statement is the one which takes effect.

So, option (1) would not be correct.
2 is correct because -- Same explanation as given above
4 is correct because -- finally gets executed no matter whether catch is executed or not and no matter whether exception is thrown or not.

Its because you have already caught your exception in the catch block of method().. Exceptions once caught are not caught again.

If you did not have a catch() block in method() AND if you had only declared that exception in method(), then the "catch2" would have been executed.

All,

Thanks for brainstorming ... I have now got a better idea than before ...

Got it, Harvinder and Srilatha !! Thanks.

Ya I kind of understand Harvinder...But not 100% clear..
Lets see what others have to say as well..

Yes. I got it..
Thanks Wouter,Santiago and Harvinder !!!

Thanks Henry !!

So, if I have the method declaration as static void pop(Map<Integer,String> m), will there be a compiler error while trying to add an int in place of a String? (the "value" part of the map)

Source: Inquisition

interface face { void meth(); } class tester extends test implements face { public void meth(){System.out.println("hello");}} class test { public static void main( String args[] ) { test test_one = new tester(); face f = test_one; // 1 f.meth(); } }

I thought this would work fine... But the answer is "Compile time error at line 1 and it will compile if that line includes a cast for face"

This is what I thought: 'test' does not implement 'face'. But, there could be a scenario in the future wherein some class could extend 'test' AND implement 'face'. So, the compiler would allow Line 1 to be compiled, and at runtime also, 'test_one' actually points to a 'tester' object that indeed implements 'face' and hence, runtime exception also will not occur.

Where have I gone wrong?

Source: Inquisition
class test { public static void main ( String [] args ) { final Integer x4 = 8; final int x = 10; switch ( x ) { case x4: System.out.println("4"); break; case x: System.out.println("x"); break; } } }

The answer given is:
Final objects are not allowed in a case statement. A final object's value can be changed whereas a final variables value cannot be changed.

I thought x4 is a final variable and its value has been set as a compile time constant. Then why is it not allowed in the case statement? If I try changing the value of x4, say, as x4++, there is a compiler error that final variables cannot be modified. So, immutability of wrapper objects is also out of picture here. Then, what is the reason for this error?

Source: Inquisition
import java.util.*; class test implements Comparator < test > { int testNumber; public static void main( String args[] ) { Set < test > s1 = new TreeSet < test > (); s1.add(new test()); s1.add(new test()); } public int compare( test t1 , test t2 ) { return t1.testNumber - t2.testNumber; } }

There is a ClassCastException on running this code which I thought is because of not properly setting the 'testNumber' instance variable, and compare() uses this unset variable for comparison.

So, I modified the code like this:
import java.util.*; class test implements Comparator < test > { test(int t) { this.testNumber = t; } int testNumber; public static void main( String args[] ) { Set < test > s1 = new TreeSet < test > (); s1.add(new test(40)); s1.add(new test(30)); } public int compare( test t1 , test t2 ) { return t1.testNumber - t2.testNumber; } }
Even now, the same exception occurs. A TreeSet can have objects whose class implements Comparator interface, right? Then what is the issue here?

Source: Inquisition

import java.util.*; class test{ public static void main(String s[]){ Map<Integer,String> map = new LinkedHashMap<Integer,String>(); Map<Integer,String> sap = new HashMap<Integer,String>(); pop(map); pop(sap); System.out.println(map.get(1)+sap.get(1)); } static void pop(Map m) { for (int i = 0; i < 10; i++) { m.put(i,i); // Line 1 } } }

On execution, there is a ClassCastException saying "java.lang.Integer cannot be converted to java.lang.String". I understand it occurs when calling get(), which tries to put an Integer into a String.

My doubt is: We have declared the generic type of the Maps to be Map<Integer,String>. Then, why does not the compiler err while compiling Line 1 where we are putting an int in a place where String is expected? (Because we have defined the Generic types to state that the Key is of type Integer and Value is of type String)

Geeta

I think this is what is happening.

(1) How come static int can be accessed with the help of this? -- A static variable can be accessed via an instance or classname or even a null reference. So, the "this" here does not matter. Then, how come "this" correctly accesses the INSTANCE variable in your code?? Its because "this" always refers to the currently executing instance. And, in this case, it accesses the inherited static instance variable.

(2) And is it possible to hide the variable in the same method? -- You are defining a variable i that is local to wine(). So, it is not hiding because the static i is inherited but the i in wine() is totally a different variable, that too, a local variable. If you want to access the value of the local i, try this code: System.out.println(i); in place of your System.out.println(this.i);. It will display 20

Hope I am making sense.