Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>You ask five questions</p> <blockquote> <p><b>1. What ways do u suggest on improving this technique of returning some dogs, with some attribute?</b></p> </blockquote> <p>Several, actually.</p> <ul> <li>Your method is static - this isn't terrible, but leads to you using another static "executeQuery", which smells of Singleton to me... </li> <li>The class "Dogs" violates an OO naming practice - plural nouns don't make good class names unless one instance of the class holds a collection of things - and it appears that Dogs is actually "Dog".</li> <li><em>HashTable</em> is all but deprecated. HashMap or ConcurrentHashMap give better performance.</li> <li>I can't see a reason to create the first part of your query with multiple appends - it's not bad, but it's less readable than it might be, so sql.append ("SELECT * FROM dogs_table WHERE "); makes a more sensible beginning if you're just going to hardcode the selected columns (*) and table name (dogs_table) anyway.</li> </ul> <blockquote> <p><b>2. rs.next() will return false for a null ResultSet, or will generate an exception</b></p> </blockquote> <p>This doesn't seem to be a question, but yes, rs.next() returns false as soon as there's no longer any rows to process.</p> <blockquote> <p><b>3. What if, while initializing a dog object from the current row of the ResultSet, something bad happens</b></p> </blockquote> <p>If "something bad happens", what you do next is up to you and your design. There's the forgiving approach (return all the rows you can), and the unforgiving (throw an exception). I tend to lean towards the "unforgiving" approach, since with the "forgiving" approach, users won't know that you haven't returned all the rows that exist - just all the ones you'd gotten before the error. But there might be cases for the forgiving approach.</p> <blockquote> <p><b>4. I think u will all agree on this one : nothing bad happens, there are no rows on the interrogation, a null value will be return.</b></p> </blockquote> <p>This isn't something on which there's an obvious <em>right</em> answer. First, it's not what's happening in the method as written. It's going to return an empty HashTable (this is what was meant by a "null object"). Second, null isn't always the answer in the "no results found" case. </p> <p>I've seen null, but I've also seen an empty result variable instead. I claim they're both correct approaches, but I prefer the empty result variable. However, it's always best to be consistent, so pick a method of returning "no results" and stick with it.</p> <blockquote> <p><b>5. I've noticed people and groups of people saying that one should split the application into layers, or levels of some kind.</b></p> </blockquote> <p>This is harder to answer than the others, without seeing the rest of your application.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload