J'éviterais ce qui suit
sql.append("SELECT * FROM ").append("dogs_table");
sql.append(" WHERE ").append(colName).append("='");
sql.append(colValue).append("'");
et utilisez à la place un PreparedStatement
avec ses méthodes de paramétrage associées (setString() ) etc. Cela évitera les problèmes avec les valeurs de colValue avoir des guillemets et des attaques par injection SQL (ou plus généralement, colValue formant une syntaxe SQL).
Je ne le ferais jamais renvoie une valeur nulle si la collection était simplement vide. Cela semble très contre-intuitif et complètement inattendu du point de vue du client.
Je ne recommanderais pas de renvoyer un null dans les conditions d'erreur, car votre client doit explicitement vérifier cela (et l'oubliera probablement). Je renverrais une collection vide si nécessaire (cela peut être analogue à votre commentaire concernant un objet nul), ou plus probablement lancerait une exception (selon les circonstances et la gravité). L'exception est utile car elle contiendra des informations relatives à l'erreur rencontrée. Null ne vous dit rien.
Que faire si vous rencontrez un problème lors de la construction d'un Dog objet ? Je pense que cela dépend de la robustesse et de la résilience que vous souhaitez pour votre application. Est-ce un problème de renvoyer un sous-ensemble de Dog s, ou serait-ce complètement catastrophique et vous devez le signaler ? C'est une exigence d'application (j'ai dû répondre à l'un ou l'autre scénario dans le passé - meilleur effort ou tout ou rien ).
Quelques observations. J'utiliserais HashMap
plutôt que l'ancien Hashtable (synchronisé pour tous les accès et, plus important encore, pas une Collection appropriée - si vous avez une Collection vous pouvez le passer à n'importe quelle autre méthode en attendant any Collection ), et StringBuilder
sur StringBuffer pour des raisons similaires. Pas un problème majeur, mais bon à savoir.
