public String read() throws IOException {
throw new IOException("Unknown");
}
About Question enthuware.ocpjp.v7.2.1209 :
Moderator: admin
-
- Posts: 47
- Joined: Mon Apr 08, 2013 7:55 pm
- Contact:
About Question enthuware.ocpjp.v7.2.1209 :
Why doesn't the compiler give error about the return statement missing ?
-
- Site Admin
- Posts: 10036
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1209 :
Because it knows for sure that the method is going to throw an exception every time it is executed. Since the outcome is deterministic at compile time, the compiler doesn't need any return value.
If you like our products and services, please help us by posting your review here.
-
- Posts: 53
- Joined: Thu Nov 22, 2012 12:01 am
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1209 :
I think others key points here are:
1) AutoCloseable's close() is not required to be idempotent. In other words, calling this close method more than once may have some visible side effect, unlike Closeable.close() which is required to have no effect if called more than once. However, implementers of this interface are strongly encouraged to make their close methods idempotent.
2) For Closeable.close(), if the resource is already closed then invoking this method has no effect.
When I did this question, I thought the Device was already closed by explicitly calling Device's closed() (the first time) and one exception could be thrown when the try-with-resources block tried to close it automatically (the second time).
So I don't fully understand the explanation "The fact that the code explicitly calls d.close() is irrelevant." and still wonder what the correct answer is. Can anyone help me out?
1) AutoCloseable's close() is not required to be idempotent. In other words, calling this close method more than once may have some visible side effect, unlike Closeable.close() which is required to have no effect if called more than once. However, implementers of this interface are strongly encouraged to make their close methods idempotent.
2) For Closeable.close(), if the resource is already closed then invoking this method has no effect.
When I did this question, I thought the Device was already closed by explicitly calling Device's closed() (the first time) and one exception could be thrown when the try-with-resources block tried to close it automatically (the second time).
So I don't fully understand the explanation "The fact that the code explicitly calls d.close() is irrelevant." and still wonder what the correct answer is. Can anyone help me out?
-
- Site Admin
- Posts: 10036
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1209 :
What you said in point 1 and 2 is correct. But it has nothing to do with this question because of the following reasons -
1. Both, AutoCloseable and Closeable are interfaces. So even though the semantics of their close methods are guided by the API documentation, the implementations are free to do what they want. Compiler cannot check or vouch for their adherence to the documentation.
2. Try with resources deals with java.lang.AutoCloseable. It doesn't care about java.io.Closeable (though Closeable does extend AutoCloseable). So the semantics of Closeable are irrelevant at this point.
3.At the end of try with resources, the close() method of AutoCloseable will be called irrespective of whether that method has already been called or not by whoever. No exception will be thrown just because some one else has already called close(). But of course, if the close() method is implemented such a way that it checks whether the resource is already closed and if that code throws an exception if it is already closed, then that is a different matter. It is not the case in code given in this question and that is why no exception is thrown. In fact, the close method given in the question is actually idempotent, so why do you think there should have been an exception?
HTH,
Paul.
1. Both, AutoCloseable and Closeable are interfaces. So even though the semantics of their close methods are guided by the API documentation, the implementations are free to do what they want. Compiler cannot check or vouch for their adherence to the documentation.
2. Try with resources deals with java.lang.AutoCloseable. It doesn't care about java.io.Closeable (though Closeable does extend AutoCloseable). So the semantics of Closeable are irrelevant at this point.
3.At the end of try with resources, the close() method of AutoCloseable will be called irrespective of whether that method has already been called or not by whoever. No exception will be thrown just because some one else has already called close(). But of course, if the close() method is implemented such a way that it checks whether the resource is already closed and if that code throws an exception if it is already closed, then that is a different matter. It is not the case in code given in this question and that is why no exception is thrown. In fact, the close method given in the question is actually idempotent, so why do you think there should have been an exception?
HTH,
Paul.
If you like our products and services, please help us by posting your review here.
-
- Posts: 53
- Joined: Thu Nov 22, 2012 12:01 am
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1209 :
This time I am very satisfied with your explanation. Thank you.
-
- Posts: 33
- Joined: Sat Feb 15, 2020 12:44 am
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1209 :
Does try-with-resources not also call open() so that open() would be called twice, as is close()? Obviously, this is not the case, but I don't understand why.
-
- Site Admin
- Posts: 10036
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1209 :
No, try-with-resources does not also call open() on its own.
What book are you following??
What book are you following??
If you like our products and services, please help us by posting your review here.
Who is online
Users browsing this forum: Bing [Bot] and 62 guests