Mauvais exemple: Ce n'est pas parce que exists() te dit que le répertoire n'existe pas que ton mkdir ne va pas échouer avec une erreur du type "le répertoire existe déjà", et inversement.
Au final, ton code deviendrai lourdingue :
try{if(!exist(dir)){mkdir(dir);}}catch(IOExceptione){if(/* exception dut à préexistence de dossier */){/* OSEF */}else{/* Erreur */}}
Et c'est en supposant que les erreurs renvoyées par exists() aient la même sémantique que les erreurs renvoyées par mkdir. Si ce n'est pas le cas, il faudra les mettre dans des try séparés. Mais du coup, l'intérêt des exceptions de séparer le bon cas du mauvais cas est perdue.
Mais sinon, s'amuser à réimplémenter de façon buggée toutes les vérifications que peut faire le mkdir() actuel dans le code qui l'appelle, c'est pas vraiment une bonne idée, surtout si ton mkdir() change souvent (ici c'est pas le cas, mais avec d'autres fonctions …).
[^] # Re: gestion des erreurs
Posté par Batchyx . En réponse à la dépêche Retour d'expérience sur Go. Évalué à 7.
Mauvais exemple: Ce n'est pas parce que exists() te dit que le répertoire n'existe pas que ton mkdir ne va pas échouer avec une erreur du type "le répertoire existe déjà", et inversement.
Au final, ton code deviendrai lourdingue :
Et c'est en supposant que les erreurs renvoyées par exists() aient la même sémantique que les erreurs renvoyées par mkdir. Si ce n'est pas le cas, il faudra les mettre dans des try séparés. Mais du coup, l'intérêt des exceptions de séparer le bon cas du mauvais cas est perdue.
Mais sinon, s'amuser à réimplémenter de façon buggée toutes les vérifications que peut faire le mkdir() actuel dans le code qui l'appelle, c'est pas vraiment une bonne idée, surtout si ton mkdir() change souvent (ici c'est pas le cas, mais avec d'autres fonctions …).