Détection de contraintes non respectées

Hello,

Lors de l'ajout d'une entrée dans une table, je fait les choses suivante dans mon code JDBC:

- J'essai d'insérer l'entrée avec une requête
- Si une exception est levée, je regarde le message (ex.getMessage()). Si celui-ci contient le nom d'une contrainte d'unicité (ou le mot primary dans le cas de la clé primaire de la table), je fait un certains nombre de traitements et je renvoi que l'entrée existe déjà.

Question: est-ce portable? Je n'en ai pas l'impression: j'ai remarqué que sous windows / mysql, les comportements sont différents, et dans certains messages d'erreurs, les noms de contraintes sont en minuscule etc... Mieux, sous un linux 64 bit, je n'ai pas le même message...

Bref, la solution "facile" serait de faire d"abord une requête vérifiant la contrainte, et ensuite d'insérer si OK. Mais c'est moche: la vérification se fait du coup deux fois (par moi et par le SGBD).

Des infos là dessus ?

Bonjour,

Le premier élément descriptif de la nature d'une exception c'est la classe à laquelle elle appartient.
Le plus propre est donc de mettre plusieurs catch: un catch sur chaque type d'exception à gérer.
Et éviter les

Code:

---

catch (Exception ex)

---

qui intercepte tous ce qui hérite de Exception et dont il est difficile de savoir de quoi il s'agit.

Oui sauf que toutes les exceptions liées à l'execution de requêtes avec JDBC sont des instances de la classe SQLException.

Donc en l'occurence pour le moment je n'ai rien trouvé de mieux que de lire ce qu'il est écrit dans le message comme indiqué plus haut.

Une erreur de contrainte de clef ou autre va générer une SQLException, sur cette exception (qui est bien sûr attrapable via un try/catch). Il est possible de récupérer le SQL state de cette erreur afin de le tester et regarder si cela correspond à une erreur de clef primaire ou autre.

Note cette solution même si elle me semble plus "propre" n'est pas vraiment portable d'un SGBD à l'autre, même si des SQL state sont communs entre certains SGBD tu finiras sûrement par en trouver un qui a voulu faire les choses différemment.

Note: la liste des SQL state sont généralement récupérables sur le site de chaque SGBD.