Page 1 of 1

About Question enthuware.ocpjp.v7.2.1202 :

Posted: Sun Jun 23, 2013 3:06 am
by The_Nick
Hi,
What do you exactly mean with " the read method read the bytes even if less than the buffer size"?
Thanks in advance.

The_Nick.

Re: About Question enthuware.ocpjp.v7.2.1202 :

Posted: Sun Jun 23, 2013 11:22 am
by admin
In the explanation:
The read method reads the bytes that are available even if the number of available bytes is less than the buffer size. The method returns the actual number of bytes read. It does not read more bytes than the size of the buffer. Hence, the need for a loop.

Re: About Question enthuware.ocpjp.v7.2.1202 :

Posted: Sun Jun 23, 2013 1:11 pm
by The_Nick
Basically what the quote says it's just that the read() method returns the amount of bytes read and that amount of bytes read will be the buffer size? nothing more?

The_Nick.

Re: About Question enthuware.ocpjp.v7.2.1202 :

Posted: Sun Jun 23, 2013 1:35 pm
by admin
No, it doesn't really say what you've mentioned. I am not sure how to put it any differently than what it already says. There are two possibilities,
1. the available number of bytes is less than the buffer size:
The read method reads the bytes that are available even if the number of available bytes is less than the buffer size. The method returns the actual number of bytes read.
2. the available number of bytes is more than the buffer size:
It does not read more bytes than the size of the buffer. Hence, the need for a loop.
I am not sure which part is not clear to you.
thank you,
Paul.

Re: About Question enthuware.ocpjp.v7.2.1202 :

Posted: Wed Jan 08, 2014 5:08 am
by Ambiorix
Why does the code try to catch java.io.InvalidClassException?

I've looked at the descriptions for both read() and write() and neither says that it can throw this exception. The code also compiles OK without it.

Re: About Question enthuware.ocpjp.v7.2.1202 :

Posted: Wed Jan 08, 2014 7:18 am
by admin
The methods says they throw IOException. So as long as you catch (or declare) IOException (or any of its superclass), you are fine. So in that sense, you don't need to catch InvalidClassException technically. At the same time, it is not technically incorrect to catch any other specific IOException either.

Remember that questions may contain code that may not make logical sense.

HTH,
Paul.

Re: About Question enthuware.ocpjp.v7.2.1202 :

Posted: Sat Jan 21, 2017 5:11 pm
by nanotasza
Can any method from the try block really throw InvalidClassException? Even if the copy(String records1, String records2) method didn't declare to throw IOException, and instead a clause catching IOException would be added under the existing one, the code would still compile!

I've selected "The program will not compile." in this question, because I knew that methods in the try block throw IOException, not InvalidClassException (also I didn't know that InvalidClassException is a subtype of IOException, but this is a different story ;)) I was expecting a compiler error like "InvalidClassException can never be thrown in the corresponding try block".

What I want to say is that what I personally learned from this question (and what other people may find educational as well) is that a piece of code like this will compile fine:

Code: Select all

public class TestException {
    public static void main(String... args){
        try {
            myMethod();
        }
        catch (MyException e) { // myMethod() throws IOException, but it is ok to catch a subclass!
            e.printStackTrace();
        }
        catch (Exception e) {
            e.printStackTrace();
        }
    }
    public static void myMethod() throws IOException{
    }

    class MyException extends IOException{
    }
}
I didn't remember that if a method throws an exception, the compiler won't complain when a subclass of this exception is caught by the caller.

Best regards,
nanotasza

Edit: Oh, now I can see that you've wrote basically the same thing above, Paul:
At the same time, it is not technically incorrect to catch any other specific IOException either.