Re-think exceptions policy

[ssloy]

@lbinria :

J'ai remarqué dans ultimaille que certaines exceptions étaient contrôlée volontairement (catch) et qu'un message été ensuite écrit sur le canal stderr. Je pense par exemple à la fonction read_by_extension.

Personnellement, je laisse toujours remonter l'erreur jusqu'à l'utilisateur quand j'écris une lib pour les raisons suivantes :

Ne pas cacher ce qui se passe Que l'utilisateur puisse la contrôler comme il le souhaite en la "catchant" (ex: écrire dans un fichier de log, reporter l'erreur dans le return du programme, ...) Permet d'éviter qu'une exception contrôlée, laisse le programme continuer tranquillement son exécution provoquant des effets de bords qui ouvre la voie à un comportement du programme non déterminé (par exemple quand on utilise read_by_extension, si le fichier n'est pas trouvé, l'erreur est catché, mais le programme continue son exec comme si de rien était, on pense traiter le maillage et on sauvegarde, produisant ainsi en sortie un fichier geogram vide) Pour ma part généralement dans une lib je laisse l'exception remonter jusqu'à l'utilisateur:

Soit telle qu'elle, si assez précise Soit spécifié, si pas assez précise, ou manque de détail sur le contexte (ex: IOException("IO Error") pas spécifique, on peut la "catcher" et en lever une plus spécifique throw FileNotFound("le fichier myfile n'existe pas")...) Très rarement je la "catche" souvent pour des considération technique Si je te remonte cela c'est que par exemple, j'aurais aimé reporté un code erreur dans mes exécutables d'exemples, quand par exemple le fichier n'est pas trouvé, ce qui me permet dans un contexte d'intégration continue de vérifier que mon MakeFile, mon programme est correcte pour linux, windows, macos.