[Dcmlib] TestMakeIcon : exit dans gdcmDocument]

[Mathieu Malaterre]

> J'avais ecrit ca pour passer le temps, lors d'une réunion ou il y avait 
> bcp de monde et lors de laquelle je m'ennuyais....
> Ca marchait tres bien tant qu'on le lancait en etant dans gdcmData.

c'est que je me disais, ou bien tu peux parfaitement copier l'image dans 
gdcm-bin...

> Je ne sais plus trop pourquoi il s'est retrouve dans 'Testing', alors 
> qu'il n'a rien a y faire (pas plus que ReadPapyrus or 
> ReadOverlays).C'etait juste un bout de code, s'appuyant sur des 
> primitives de bas niveau, qui va recuperer/positionner des info un peu 
> exotiques.
> Il suffisait d'ajouter GDCM_DATA_ROOT dans le nom du fichier pour que ca 
> passe.

ja sais mais mon point c'etait de montrer que meme avec un dashboard 
gdcm reponds oui tout ce passe bien ... alors que c'est archi faux !

> Personne, en effet.
> Pas plus toi que les autres.
> Je prend une heure demain matin, j'ajoute des try-catch dans tous les 
> tests.
> Est-ce que cela changera le problème?

C'est tres gentil, mais non je ne pense pas que ca reglera le probleme. 
Un utilisateur va se lancer dans l'utilisation de gdcm. Il va faire une 
mini demo (new gdcm::File) avec une typo dans le nom de fichier... et 
gdcm va lui dire ben oui ta va bien j'ai bien lu le fichier inexistant.

Donc non: on ne fais pas de try catch. Le seul try catch en c++ qui est 
possible c'est celui du 'new'. Genre on atteint les limites physique de 
la machine et la ben oui faut bien faire un traitement de derniere 
chance. Mais entre nous tu ne peux pas demander a un util de faire des 
try catch de partout dans son code.

En revanche tu peux parfaitement faire:

gdcm::Serie s =
s.SetDirectory( "bla" );

try
   {
   s.GetFirstSerie()
   }
catch
   {
    cerr << "Echec parce que:" << error.Print() ...
   }

dans la meme genre l'utilisateur devrait mettre un try/catch au moment 
de l'ecriture:

gdcm::FileHelper f

try
   f.Write()
catch
   cerr << "Echec"


Entre parenthese je sais meme pas si c'est possible de mettre un try 
catch sur la construction d'un objet: comment tu fais pour le declarer:

try
{
    gdcm::File f("");
}
catch
{
}

f.GetImageData() -> echec du compilo

-> on est sortie du scope , on n'a plus access a f. Ca veut dire que ne 
peut plus faire d'objet sur la pile, a chq fois il faudrait faire un 
pointeur puis affectation:

gdcm::File *f;

try
{
    f = new gdcm::File("");
}
catch
{
}


DU DELIRE !

> La derniere version du diagramme de classes pour décrire l'entete ne me 
> choque plus.
> En revanche, la partie 'lecture/decompression' devra probablement etre 
> entierement réécrite.
> Vouloir lire *tout* le fichier d'un seul coup, c'est du pur délire !
> Lorsqu'on aura des multiframes de 2 Giga Octets, comme ceux de 
> Jean-Michel Rouet
> (on en a deja, de plus petits, de 200 MegaOctets), il faudra bien qu'on 
> fasse du frame by frame reading, pour permetre a l'utilisateur de de 
> garder *lors de la lecture* que les frames dont il a besoin (et pas une 
> fois que tout est lu ...).
> Et la, ca va secouer ...


Exact je n'y avais pas penser mais tu as parfaitement raison. Dans le 
cas d'image de ce type il faut pouvoir faire qlq chose du genre:


gdcm::File f(); //vide
s.SetVolumeOfInterest(0,512,0,512,0,10);

try
    f.Read()
catch
    cerr << "Echec lors de la lecture"

C'est vraiment important de faire le VRAI traitement en dehors de la 
construction de l'image IMHO.


> Pourrais-tu nous les communiquer.

C'est sur papier, je recopie, et je fais un mail. J'espere que mes notes 
seront relisible. En gros j'applique la methode XP: j'ecris d'abords les 
tests et ensuite j'ecris la lib.

Mathieu