Bonjour
 
j'ai une date en string qui me faut convertir en java.sql.Date.
 
Donc j'utilise un parser pour la convertir. (SimpleDateFormat)
 
Le pb c'est que la date peut avoir plusieurs format different :
 
dd/MM/yyyy ou dd.MM-yyyy ou dd.MM.yyyy
 
Comment résoudre ce pb sans utiliser les exceptions ?

Tu ne peux pas différencier tes cas avant d'arriver au "parsage" ?
et pourquoi ne pas vouloir utiliser les exceptions ?

Faire des tests avec des expressions régulières ?
\d{2}/\d{2}/\d{4} et \d{2}-\d{2}-\d{4}

 
Bonne idée ... Quoique pas assez propre  , mais je vais tenter    
 
Sinon je veux pas utiliser les exceptions car j'aime trop manipuler les exceptions, c'est sale    
 
Une bonne appli, c'est une appli sans exception  

 
Même esprit que zedar, je teste    

c'est quoi ton problème avec les exceptions ?

Euh ton point de vue sur les exceptions est.. intéressant
 
sinon pour différencier avant, tu fais juste une recherche du caractère '/', '-' ou '.' et tu auras ton format (j'ai regardé dans la doc et pas trouvé moyen d'avoir un format multiple en argument...)

Plus fondamentalement, tu ne devrais probablement pas arriver à un point où une String à convertir en java.sql.Date peut avoir plusieurs formats.
 
Je ne serais pas étonné qu'il y ait un problème de design en amont, et c'est part là que je commencerais.
 
A défaut, on en arrive à des contorsions inélégantes et qui rendent le code peu maintenable.
 
Maintenant, je ne vois pas pq tu ne veux pas utiliser les exceptions ?! Tu crées une méthode générique isValid(String  date, String format) dans une classe relative aux Dates qui réalise le test; tu en crées une autre qui fait la conversion et le tour est joué.

Ca ne suffira pas. Le plus simple et le plus efficace pour tester une date, c'est pas ça.  

sircam: bah euh "le problème de design" ici c'est simplement une certaine souplesse qu'on veut laisser aux utilisateurs j'imagine; le truc qu'il doit parser est probablement une entrée humaine...

Ok, mais la date fournit, c'est une date donnée pas un calendrier Javascript, et sur certains postes, il me donne de droles de format.
 
Sinon merci

L'entrée devrait être normalisée avant d'arriver à ce qui ressemble à une couche data access, plutôt que de mélanger les deux.

 
Egalement, l'utilisateur n'est aps obligé d'utiliser le calendrier javascript

Ouep, d'accord avec Sircam, surtout si l'entrée n'est pas humaine, essaie de regarder en aval comment tu peux arriver à ces cas là, ça semble qd mm bizarre (aval c'est bien avant ?)
 
EDIT : manqué c'était amont

ha oui, c'est le package qui te fait dire ça, javais pas tilté

 
t'es compliqué
mais je voudrais savoir ce que tu veut dire avec