[Dcmlib] TestMakeIcon : exit dans gdcmDocument]

[Mathieu Malaterre]

Jean-Pierre Roux wrote:
> 
> Mathieu Malaterre wrote:
> 
>>
>> J'ai rajouter une ligne: gdcmDocument fais un exit si tu lui passes un 
>> nom de fichier qui n'existe pas... le test TestMakeIcon passe une 
>> image sans full path...
>>
> 
> Ce qui existait n'etait pas tres satisfaisant (on ne prevenait pas 
> l'appelant si on n'arrivait pas a ouvrir un fichier ...)
> Je ne savais pas comment faire, alors je l'avais laissé comme ca, me 
> disant qu'une methode finirait bien par renoyer un copde d'erreur, un 
> peu plus loin.
> L'exemple de TestMakeIcon a montre qu'il n'en n'etait rien, puisque le 
> test s'effectuait 'successfull', alors que le full path name de l'image 
> etait faux.
> 
> La solution actuelle, qui consiste a faire un 'exit' au plus profond des 
> entrailles de gdcm me choque.
> Ce n'est pas a une fonction de tres bas niveau de dire si le programme 
> de l'utilisateur s'arrete ou non!
> Il faut pouvoir informer l'utilisateur que qq chose a foiré dans le 
> constructeur.
> 
> Je ne maitrise pas assez les subtilites du C++, mais ne serait-il pas 
> possible de transposer l'equivalent du 'errno' du C (une variable 
> globale -en C- qui indique le code d'erreur dans le cas ou la valeur 
> retournée par la fonction n'indique pas -ou indique de maniere 
> insuffisante- que ca a casse, ou *ce qui* a casse)?
> 
> Dans la version actuelle (avec exit), la seule maniere pour 
> l'utilisateur d'etre sur que son programme ne lui pete pas dans les 
> doigts serait de verifier (par fopen puis fclose) que son fichier est 
> bien ouvrable.
> Ce qui va encore ralentir le bazar ...

C'est encore un des gros problemes de gdcm, je ne suis vraiment pas 
satisfait de l'archi. Deja le premiere des choses qui me rend dingue 
c'est qu'un test qui ne marche pas depuis bientot 2 mois a toujours ete 
vert (jusque qu'e ce que j'utilise .Net FreeC++ + nmake).

Mais effectivement pour effleurer le probleme de la propagation d'erreur 
beaucoup de chose sont faites a 'creation time'. On creer un objet 
gdcm::File a partir d'un file name, un constructeur c++ ne retourne rien 
sur la pile. Donc la seule solution c'est de lancer une exception. 
Jusqu'a le rien de bien choquant. Mais mon gros probleme c'est que 
PERSONNE, je dis bien PERSONNE ne fais de try/catch sur une construction 
d'objet c++. C'est du pur delire.

Il y a un profond probleme du au system d'heritage de gdcm qui me 
deplait de plus en plus. Et je suis de tente de demarrer un projet from 
scratch pour me debarrasser definitevement de ca. Au passage est-ce que 
d'autre personne partage mon opinion: cad qu'il y a aeu des choix fais a 
la base de gdcm qui sont faux et qui font que meme un couche de 
refactoring(*) ne suffirait pas regler ?

J'ai commencer a dresser la liste des attentes d'une lib IO pour le cas 
des images DICOM et je crois avoir fais le tour.

Mathieu
(*) Refactoring: Improving the Design of Existing Code
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts