performance enter try ou test

Bonjour,

J'ai 2 possibiités pour le chargement d'un objet de ma bdd:

Soit faire un test si l'objet existe en base de données si oui -> je le charge sinon -> je le crée d'abord.

Soit faire tout le temps le chargement de l'objet(sans test) et si il n'existe pas en base alors le créer dans un catch au niveau l'exception qui remonte

Je souhaiterais avoir vos opinions sur la solution la plus performante, sachant que le cas ou l'objet n'existe pas est tout de même assez rare.

Merci

Si le cas où l'objet n'existe pas peut être déduit du contexte métier, alors il faut que tu le trouves à partir de là. Il ne faut pas le trouver à partir de la lecture de la base, mais à partir de ce que tu as formalisé du niveau métier.

Si tu ne peux pas le déduire, mais que ce cas, bien que rare, soit correct, alors il faut que tu fasses le test d'abord : tu es dans une situation normale, donc tu la traites par le flux try, pas par le flux catch.

Si ce cas est prévisible mais qu'il s'agit, selon de ce que tu peux craindre des choses et toutes étant égales par ailleurs mais chacun fait squipeutavecsquila, bref c'est un bug :marteau:, alors tu le traites par le catch.

les catch sont censé servir aux cas d'exception. Si c'est un objet en base de donnée, un simple select suffit à faire la test. Si t'as un row tu le retourne, si t'en a pas, tu le crée. Il faut aps esayer à tout prix de lire un row qui n'existe pas et traiter le "pas d'objet" dans le JDBCException. D'abord, tu risque de catcher descas d'erreur comme si ils voulaient dire 'pas d'objet' alors que l'erreur est autre, ensuite ca rend le code moins lisible. Enfin, si pour une raison ou une autre ta méthoe métier qui se base sur le try catch est appelée dans un finally, tu va perdre l'exception d'origne. Exemple

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public User getCurrentuser(){ try { return getUser(login); } catch (MetierObjetExistePasException e){ return createUser(login); } }   .... try { ....// méthode qui déclenche un NullPointerException par exemple } finally { // pour une raison ou un autre, on doit garantir que unTruc() sera appelé sur l'utilisateur courant getCurrentUser().setUnTruc(); // Si MetierObjetExistePasException // déclenché et traité dans getCurrentUser, NullPointerException // n'existe plus! }

---

Enfin je dirais que tu ne sais jamais comment ton application va évoluer. Peut être que demain, un cas d'utilisation impliquera que 80% des objets créés ne sont pas dans la BD. Cela impliquera alors une très grande quantité de try catch ce qui va ralentir énormément ton application.