Discussion :

[Maniak]

Maniak, merci de me faire passer pour un plouc au fait.

Désolé, j'étais en mode pinaillage
(comment ça comme d'hab ?

(d'autant que je suis loin de toujours suivre ce que je raconte moi-même ici. j'essaye cela dit


(hey, y a plus d'option pour désactiver les smileys ? c'est un scandale)

[abelman]

On va continuer par MP avant qu'un modo ne nous tombe dessus

Y a pas d'option pour ça non plus si je fais nouvelle discussion non

ah, trouvé.
C'est en mode éditeur basique que l'option n'apparait pas. Je viens de mettre l'éditeur standard et là il y a l'option

Mais bon, logiquement elle devrait être partout non ?

Ben moi l'ai toujours eu. Je ne sais pas si c'est du au fait d'être modo. Je vais me renseigner

PS: Fait de la place dans ta boite à MP stp. elle est pleine.
On continue en MP

@+

[zeavan]

merci pour la confirmation maniak.

[abelman]

Faire qqch comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
catch ( Exception ex) { throw new MyException(ex); }

En général je le fais pour savoir où est arrivé l'exception.
Je m'explique.

Les exceptions, je les utilise surtout pour:
- informer l'utilisateur, si il y en a un :p (Dans les services il y en a pas)
- Si il y a un utilisateur et donc une interface, remettre l'interface dans un état "correct" pour l'utilisateur si besoin (Remettre des boutons à enable=true, etc...)
- Tracer l'exception dans un fichier (dans le code appellant)

Je suis en train de faire une librairie de composants/ Classes.
Voici un squelette d'exemple de méthodes qui utiliseront cette librairie:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
class CMaClass
{
    void FaisMoiUnTruc(Object obj)
    {
        try
        {
         // Première partie du truc
        // Deuxième partie du truc
        // Compression (Je peux éventuellement tester validité des arguments avant mais ce code n'étant pas forcement du code utilisateur, je laisse les exceptions sur les arguments se propager.
        CFileCompressor.CompressFile(@"c:\fichier.txt", @"c:\fichier.gz", ECompressionFormat.Gzip);
        // Traitement XXX
 
         }
         catch (CFileCompressorException)
        {
            // Une erreur s'est produite lors de la compression fichier.
           // Je le sais car c'est CFileCompressorException
        }
        catch (CUneautreDeMesExceptionPersoXXX)
        {
            // Une erreur s'est produite lors du traitement XXX
        }
        // Suite des autres catch
        finally
        {
        }
    }
};

J'ai toujours pensé que les try catch étant couteux, si je dois en mettre, je ne met des catchs que à la fin du traitement (sauf cas rare). Ce qui m'evite d'en mettre plusieurs dans la même méthode.

Avec ma méthode FaisMoiUnTruc, si je laisse propager ArgumentException depuis ma classe CFileCompressor, je ne saurais pas dans quelle composant cela est arrivé à moins de faire un execption.ToString() en mode débug (pas envisageable en prod)

C'est pour cela que je décore au maximum les exceptions qui peuvent arriver dans mes composants.
Je les décore aussi pour masquer les erreurs de base de données.

Voilà

[Maniak]

J'ai toujours pensé que les try catch étant couteux,

À moins de les mettre en boucle, pas trop. Donc faut pas hésiter à les mettre au niveau le plus approprié, et ne (surtout) pas chercher à les regrouper par souci de performances :)

Dans le même genre, un using n'est jamais qu'un try/finally déguisé. Est-ce que c'est une raison pour ne pas en mettre partout ? :)

[abelman]

J'ai toujours pensé que les try catch étant couteux,

À moins de les mettre en boucle, pas trop. Donc faut pas hésiter à les mettre au niveau le plus approprié, et ne (surtout) pas chercher à les regrouper par souci de performances

mouais ...
Pas très convaincu quand même ... et puis ça alourdi mon code

[Keihilin]

Un try/catch n'est pas spécialement coûteux...

Lever une exception par contre, c'est assez coûteux. Mais il faut relativiser ce coût...Plus la complexité d'une méthode ou d'un traitement augmente, plus le coût d'une levée d'exception devient négligeable.

Abelman, je crois comprendre plus ou moins ton besoin, mais je ne suis pas convaincu à 100% que la décoration apporte vraiment un gros avantage...Sauf si on est dans le cas que j'ai cîté dans mon 1er message. Mais ce genre de cas n'inclut sûrement pas ArgumentNullException.

[Maniak]

Lever une exception par contre, c'est assez coûteux. Mais il faut relativiser ce coût...Plus la complexité d'une méthode ou d'un traitement augmente, plus le coût d'une levée d'exception devient négligeable.

Et vu que lever une exception est censé être rare (pas utilisé comme un mega-return-croisé-goto), c'est globalement négligeable dans tous les cas.

Si on a un problème de perfs parce qu'on balance plein d'exceptions pour des raisons autres que pour une erreur non-gérable sur place, le problème ne vient pas des exceptions mais de leur utilisation :)

[neo.51]

Quand un applis a des problème de performances dues à la levé d'exception, la pluspart du temps c'est parce que certainnes personnes utilisent les exceptions pour vérifier la saisie coté UI et/ou n'arretent pas un traitement à temps lorsqu'une exception est levée.

Je suis loin d'être un spécialiste dans la gestion des exceptions, mais de bases les bonnes pratiques sont quand même :
-Blinder la partie UI (une saisie ne doit pas lever une exception si le format n'est pas correct par exemple).
-S'assurer qu'une fois qu'une exception est levée le traitement de l'exception remet l'applis dans un état "sain", sinon on déclanche des exceptions en cascade. D'ou l'interet d'identifier précisément l'exception, si je fais un catch exception ex je vais tout ramasser, ce que je sais traiter pour remettre l'applis dans un état sain, mais aussi toute les autres. Autant traiter celle que je sais traiter et si je tombe sur une que je sais pas traiter, encore vaut parfois mieux faire crasher l'applis que d'éffectuer une opération non approprié.

Le catch d'une exception spécifique nous force à réflechir comment traiter les exception au cas par cas mais de mannière ciblée.

[neguib]

...Le catch d'une exception spécifique nous force à réflechir comment traiter les exception au cas par cas mais de mannière ciblée.

Je dirais même plus,
la gestion d'exception se conçoit avant de s'implémenter

[abelman]

Merci à tous,

Je vais continuer dans ma direction ...

Certaines réponses ont changé mon point de vue. Alors n'hésitez pas à laisser d'autres avis.

[Maniak]

la gestion d'exception se conçoit avant de s'implémenter

Oui enfin si on pouvait tout concevoir avant d'implémenter, waterfall fonctionnerait. C'est pas le cas

[abelman]

Re,

Mon but principal est de pouvoir savoir dans quelle classe/méthode est arrivé une exception sans avoir à utiliser le stackTrace ou Exception.ToString. Pour cela j'utilisais la décoration d'exception comme montré dans les extraits de code plus haut.

Alors après quelques experimentations et moult lectures mon point de vue a changé.

Voici les principes que j'essaye d'appliquer lors de la gestion d'exception dans ma bibliothèque de composants:

- Si je n'ai pas de code particulier à executer lorsqu'une exception donnée se produit, je ne fais plus de catch sur cette exception. Quelqu'un l'a dit plus haut mais je ne sais plus qui ...

- Je catch donc toutes les exceptions avec un seul "catch (Exception ex)", et je me sers de la propriété Data (.NET 2.0 uniquement) pour ajouter des informations particulières à l'exception

- Je ne fais plus un "throw new MonExceptionPerso" mais juste un throw;

- Si je veux que certains type d'exceptions (OutOfMemoryException par exemple) n'ai pas leur propriété Data modifiée, je rajoute un catch spécifque pour elles dans lequel je fais juste un throw;

Comme le code vaut toujours mieuw qu'un long discours voici ce que ça donne. N'hésitez pas à dire ce que vous en penser

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
			try
			{
				// Read file to compress
				inFileStream = new FileStream(sFileToCompress, FileMode.Open, FileAccess.Read, FileShare.Read);
				inBuffer = new byte[inFileStream.Length];
				inFileStream.Read(inBuffer, 0, inBuffer.Length);
				// Compression
				if (bFailOnExistOutFile)
					outFileMode = FileMode.CreateNew;
				else
					outFileMode = FileMode.Create;
				outFileStream = new FileStream(sArchiveFile, outFileMode, FileAccess.Write, FileShare.Read);
				if (eFormat == ECompressionFormat.Gzip)
					outCompressedStream = new GZipStream(outFileStream, CompressionMode.Compress);
				else
					outCompressedStream = new DeflateStream(outFileStream, CompressionMode.Compress);
				outCompressedStream.Write(inBuffer, 0, inBuffer.Length);
			}
			catch (OutOfMemoryException)
			{
				throw;
			}
			catch (Exception ex)
			{
				// Failed to compress file in Gzip format
				ex.Data.Add("AteoSystem.IO.CFileCompressor", String.Format(Resources.StrFCompressFailed, sFileToCompress, sArchiveFile, eFormat));
				throw;
			}

dans le code appellant cela donnerait ceci comme exemple d'exploitation.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
try
{
    CompressFile(...)
}
catch(SecurityException ex)
{
	foreach (object key in ex.Data.Keys)
	{
		Console.WriteLine(String.Format("{0} : {1}", key, ex.Data[key]));
	}
	Console.WriteLine(string.Format("{0}: {1}", ex.GetType(), ex.Message));
}

[abelman]

la gestion d'exception se conçoit avant de s'implémenter

Oui enfin si on pouvait tout concevoir avant d'implémenter, waterfall fonctionnerait. C'est pas le cas

c'est quoi waterfall?

[Maniak]

c'est quoi waterfall?

Janvier 2006 : des analystes pondent 3kg de docs sur ce qu'un projet doit faire.
Mars 2006 : des designers pondent 10kg de docs sur les moindres détails de l'organisation, la structure, la composition du projet.
Mai 2006 : des programmeurs pondent du code à la chaîne enfermés dans une pièce mal éclairée dans la cave.
Mai 2007 : des testeurs passent leur temps à essayer de tester les moindres recoins de l'appli et remplissent 20kg de docs sur tous les bugs rencontrés.
Juillet 2007 : les analystes révisent leurs docs et intègrent toutes les nouvelles décisions, les nouvelles orientations, les résolutions de problèmes pas prévus au départ
Septembre 2007 : les designers révisent leurs docs et intègrent leurs versions des changements
Décembre 2007 : la nouvelle équipe de programmeurs passe les fêtes dans la cave à essayer de faire rentrer tous les changements dans le code monolithique existant pondu par des gens dont on se demande comment ils ont pu pondre ça
Juillet 2008 : les testeurs y retournent
...


Une (longue) phase après l'autre, communication uniquement de haut en bas, waterfall.

Il y a des versions "rapides" qui tentent de réduire autant que possible la durée de chaque phase histoire que le feedback qui n'arrive que pendant le développement remonte tout en haut moins lentement, mais ça reste une usine à gaz monstrueusement inefficace. Ceux qui ont eu droit à la certif sur MSF (seulement les MCSD je présume) en ont un bon exemple :)

Très lié au BDUF (Big Design Up Front) qui consiste à passer des lustres à essayer de *tout* prévoir dès le tout début, et à présumer qu'il suffit de suivre la paperasse ensuite pour que tout se fasse sans problème.
Comme si les données d'un projet pouvaient être figées au début et ne changeaient jamais après.

http://c2.com/cgi/wiki?search=waterfall pour plus de détails, en particulier http://c2.com/cgi/wiki?WaterFall

À comparer à http://c2.com/cgi/wiki?search=agile

[defuse]

Je viens de passer la journée a lire des centaines de blogs, d'articles, à (re)scruter c2.com et joel on software, et c'est un véritable foutoir.

Personne n'arrive à déterminer quelle est la quantité exacte de design qu'il faut injecter dans la phase qui précède le codage. Il y a les pro-BDUP, les pro-Agile (qui se différencient souvent des pro-XP), les médiateurs ("50/50"), les relativistes ("ça dépend") et les désespérés qui affirment qu'il n'y a pas de solutions reproductibles, tout se passe au feeling/à la chance. Je commence à pencher pour cette dernière catégorie, à mon grand regret (sans doute par manque d'expérience).

[Maniak]

Personne n'arrive à déterminer quelle est la quantité exacte de design qu'il faut injecter dans la phase qui précède le codage.

Normal, vu la quantité de variations qu'il y a

Il y a les pro-BDUP,

Espèce en voie de disparition (espérons). Enfin s'il y a un endroit où ça durera plus longtemps, ce sera probablement en france. Vu l'adoration qu'il y a ici pour les kilos de paperasse inutile. Et l'absence totale de formation valable. Et l'obstination des employeurs à se baser sur le niveau de diplôme alors que c'est particulièrement insignifiant dans ce domaine. Bref.

les pro-Agile (qui se différencient souvent des pro-XP),

Normal aussi. XP est une des méthod(ologi)es Agile, mais pas la seule

les médiateurs ("50/50"), les relativistes ("ça dépend") et les désespérés qui affirment qu'il n'y a pas de solutions reproductibles, tout se passe au feeling/à la chance. Je commence à pencher pour cette dernière catégorie, à mon grand regret (sans doute par manque d'expérience).

Côté Agile ça penche plutôt pour ça aussi. Selon les méthodes il y a plus ou moins de paperasse 'obligatoire' prévue, mais dans l'ensemble, c'est toujours le même principe qu'on retrouve. Combien de paperasse faut-il ? -> le strict nécessaire, pas plus. Et sous forme facilement jetable vu que la paperasse en question a tendance à évoluer/changer en permanence.

Tout n'est qu'une question d'équilibre, et les méthodes Agile servent à rechercher cet équilibre. Sans pour autant chercher à imposer une recette magique censée marcher pour tout (ça c'est le truc du BDUF, et on sait comment ça se finit). L'objectif des méthodes Agile est de bien résister aux changements. Ou plutôt que les changements soient bienvenus. Alors qu'avec les méthodes 'à l'ancienne', les changements sont plutôt accueillis avec des sueurs froides et à grands coups de "argh mais ça va encore tout casser, qu'est-ce qu'ils ont à changer d'avis sans arrêt alors qu'on leur avait pourtant demandé d'être sûrs *avant*".

Après, le problème c'est pour arriver à trouver l'équilibre en question. S'il n'y a pas de formule magique mais juste une série de principes, conseils, trucs & astuces, c'est bien parce qu'au final, c'est l'expérience qui compte le plus. D'où les 2 meilleures méthodes connues pour y passer : être dans un environnement favorable et pouvoir s'offrir les services d'un coach (pas la moindre idée de s'il y en a en france) ou être dans un environnement 'compatible' et pouvoir faire de (très) nombreux tests dans ce sens. Sans pour autant que ça empêche d'avancer le 'vrai' boulot, quitte à ce que la période 'tatonnements' se fasse dans un coin perso entre deux séances sur les 'vrais' projets.

Perso, je suis passé par la phase bidouille (au début, faut bien commencer , la phase BDUF (j'y ai cru un bon moment), phase bidouille un peu mieux organisée (quand j'ai arrêté de croire au BDUF) et maintenant phase Agile/XP (quand j'ai découvert l'existence de tout ça . Donc TDD depuis 6 mois, gros boulot sur tout ce qui est refactoring, design du code etc, et à compter du mois prochain, autant de pratiques supplémentaires qu'il sera possible de caser. Pair programming, planning game etc, aidé par un changement de job vu que dans le précédent, c'était peine perdue d'essayer de faire quoi que ce soit d'organisé... Bel exemple d'environnement pas ni compatible, ni favorable (que ce soit pour Agile ou pour BDUF d'ailleurs. soulagé d'en être parti


Bref, tout ce pavé pour dire :
- oui, c'est compliqué
- non, ce n'est pas d'une clarté phénoménale
- oui, il y a une *tonne* de lecture à faire
- oui, il y a des *tonnes* d'essais à faire
- oui, il faut *beaucoup* de temps pour absorber tout ça
- oui, l'objectif final vaut le coup (pour peu qu'on s'intéresse sérieusement au sujet). N'importe quelle méthode est meilleure que le 'codage à vue'.