About Question enthuware.ocpjp.v7.2.1198 :

[The_Nick]

Hi everyone,
I have noticed that in the right answer by you indicated, it's not declared or caught the SQLException. Such exception is a Checked and thus must be caught or declared. That's why I chose answer number 3.
Even though it does nothing when caught at least it catches it. You can say it's only a snippet and it might have had declared in the not shown bit of code.. but still would not be clear. At least it's my opinion.

The_Nick.

[admin]

The objective of the question is to test how to work with resources that you want to work with in a block of code. Since you are opening Statement and ResultSet in the given block of code, you should close it at the end of the block and option 1 is the right way to do it.

As you mentioned, it is not complete code listing and propagation of an exception is not really an issue here.

HTH,
Paul.

[EpicWestern]

As you mentioned, it is not complete code listing and propagation of an exception is not really an issue here.

While its dubious that there's an implied correct catch block for option 1, options 2 and 4 clearly don't have one since there's a finally block. So your explanations are insufficient. Furthermore, option 4 doesn't compile due to a duplicate rs.

[EpicWestern]

While its dubious that there's an implied correct catch block for option 1, options 2 and 4 clearly don't have one since there's a finally block.

Actually i guess the whole statements could be wrapped in try/catch blocks so I suppose they aren't necessarily wrong. Still a lot of assuming to do especially since you usually say "assume try/catch blocks are valid" in other questions.

[admin]

"assume try/catch blocks are valid" is mentioned wherever the code listing is otherwise complete. In this question, the code listings are so obviously incomplete. They will not be complete even if you mention imports because there is no class declaration, or even a method declaration.

Also, none of the options is about compilation error. So I do not think there is any need to mention about exceptions that might be thrown by the code snippets.

thank you,
Paul.

[tn1408]

Hello,
What is the meaning of the phrase: "given that the database connection is to be reused" with regard to the question?
In other words, would the answer be any different if the question is only: (without the phrase)
Which of the following illustrates a good coding practice?
Thanks

Tony,

[admin]

If the connection is not to be reused (which may be appropriate in some situations), then the code should close the connection object. So none of the options illustrate a good coding practice in that case.
HTH,
Paul.

[bptoth]

I second to the above comments regarding SQLException. In its current form this question is misleading.

[admin]

You will see similar incomplete code listings in in the real exam as well. Your answer needs to be based only on what is shown and asked in the question. In the given code listing (of the correct option), you are working with Statement and ResultSet, and those are the objects you need to close. You don't know or care about anything else.

For this reason, I don't think there is any issue with the option.

HTH,
Paul.

[dieterdde]

You will see similar incomplete code listings in in the real exam as well. Your answer needs to be based only on what is shown and asked in the question. In the given code listing (of the correct option), you are working with Statement and ResultSet, and those are the objects you need to close. You don't know or care about anything else.

For this reason, I don't think there is any issue with the option.

HTH,
Paul.

I selected option #3 specifically because of the requirement "database connection to be reused". For me that means: make sure you don't close the connection, and that you keep the connection alive.

But if you don't handle the potential SQL Exception with a catch, it means your program will exit when it encounters an SQLexception. An exception might be thrown when the resources are getting auto-closed, or in the hypothetical code that says //do something with the row

My reasoning here was dead simple: if your program craps out, then no code is running anymore, which also means no re-use of your connection object, as that will obviously be closed when the program exits abruptly.

Hence, all the stuff about closing Statement and closing ResultSet, whether explicitly or implicitly, for me felt completely irrelevant in regards to re-using a connection object, because neither of them is closing the connection object.

Of course catching an exception and not doing anything with it, is not considered good coding practice, because you won't know if something happened and what happened exactly. But good coding practice is more subjective than the requirement of re-use of the connection object. So I gave more weight to the re-use part as to be the #1 priority, which means exceptions have to be handled, or the program will die if any exception = connection closed.

In any case, not to have error handling code should also be considered bad coding practice, unless it's a public API and you want the exception to be propagated, you should probably handle exceptions, right? The thing is, with the code given, we simply don't know if the method actually declares that it throws any exception, or if the given code is wrapped already in a try/catch block etc.

Even if the question would have stated that no exception will be thrown, I still would have taken #3. Just doesn't feel right not to handle the SQLException. I've seen it like 1000 times in the book I'm studying, which tells me the authors find it important. Same with IOException and file handling, code examples generally always use catch(IOException e) ...

Please share your thoughts.

Cheers,
Dieter

[admin]

But if you don't handle the potential SQL Exception with a catch, it means your program will exit when it encounters an SQLexception.

Your starting premise is incorrect. Why would an uncaught SQLException mean that the program will exit? Think about it. Would you like your servlet container or EE Container to exit just because some query caused an SQLException?


The question wants you to not close the Connection object. But you should certainly close Statement and ResultSet as soon as your are done with them to release any resources occupied by them. This is not irrelevant. It is very much relevant for any JDBC code. That is exactly what option 1 does and is therefore the correct option.

In many cases, Connections are managed by a connection pool and you should not let close() be called on a Connection object by your application code.

-Paul.

[dieterdde]

Hi Paul,

please don't get me wrong, I'm not saying closing a ResultSet or Statement is irrelevant. I know it's relevant in terms of releasing resources. What I'm saying is that it's not relevant towards the aim of re-using a Connection object. You can close the ResultSet or you can keep it open, but it has no bearing on the re-use of the Connection, which I understood was the main objective of the question, no?

Option 3 uses try-with-resources, so it's gonna close the Statement & ResultSet, so that's covered anyways!

Would you like your servlet container or EE Container to exit just because some query caused an SQLException?

No. This is why I chose option #3. We can't make any assumptions about code that is not shown, so I can't assume that option 1 would handle the exception and avoid exit. Option 3 is the only one that handles the potential exception (visibly).

Anyways, from your answers, it is clear, that the real objective of the question is about identifying the coding practice where you properly close your resources when they're no longer needed, hence maybe it would have been better to leave out the whole thing about the re-use of the Connection tidbit. Or maybe my brain is just wrongly wired.

Sometimes these little tidbits of extra information can cause a completely different train of thought, which might be completely besides the original intended objective. I generally try to use try-with-resources all the time, as then I know things will get auto-closed and I don't have to do it explicitly.

In any case, thanks for all the time you spend here sharing your knowledge and insight, very cool. My aspiration is one day to become a Java expert like you

I'm a programming novice, and started learning Java since February this year, achieving OCA7 in March. Started studying for OCP7 beginning of May, and am taking the exam this Thursday.

Did the objective wise tests which were a mixed bag. Some of them did very well, some of them failed. Usually because the book (K&B OCA/OCP7) didn't deal with the topics!

Yesterday, took for the first time a full test, the first standard one, and got 92%, but it did have maybe 9 or 10 questions that i had seen before, so its not fully representative of a real score.

So today, skipped to the final day test (unique) and got 82%. I found it very hard. I was also quite tired to be honest from all the studying.

Hopefully I'll feel more rested on Thursday for the actual exam!

Fingers crossed!

Cheers,
Dieter

[chandu1987]

I don't still see why option 3 is wrong. createStatement, executeQuery and next methods threw checked exceptions which needs to be caught. I even tried to compile with option 1 and it gave me compilation error, but option 3 compiled fine.

[admin]

I don't still see why option 3 is wrong. createStatement, executeQuery and next methods threw checked exceptions which needs to be caught.

Not true. The enclosing method can also just declare the exception in its throws clause.

I even tried to compile with option 1 and it gave me compilation error, but option 3 compiled fine.

Question is about good coding practice. Not about compilation.