Reprise du message précédent :
Salut à vous,
 
J'ai une petite question con sur les habitudes de chacun.
 
J’essaye généralement d'avoir le moins de block try catch finaly.
 
Bien sûr quand je dois créer ce type de bloc je m'obstine à tout architecturer bien pour utiliser de façon cohérente le bloc finaly, je catch aussi les exceptions spécifique, pas de gros bloc exception.
 
Je voulais connaitre votre habitude de ce côté-là ?

Y a rien d'anormal à utiliser le t/c/f, bien au contraire !
Après s'il y a des exceptions non managées, tu les rejettes, mais sinon tu les traites.

Je fais pas mal de spécialisations de la classe Exception pour avoir quelque chose de très propre et explicite.

Par contre, je trouve qu'il vaut mieux pas utiliser le t/c/f de façon laborieuse au lieu d'utiliser des conditions if/then/else, car on y perd beaucoup sur le côté performance (testé et pas approuvé )

Le finally je m'en sers souvent quand je travaille avec des flux (réseau, fichiers) pour les fermer proprement.
C'est plus rare avec un datacontext, en général, mon using se trouve dans la portion "try".

Ba c'est comme tout, y a de bonnes et de mauvaises utilisations. Genre dans un bloc try/catch tu ouvres une connec vers une base de données, si jamais un truc inattendu arrive et que tu sors du try, t'es bien content de pouvoir fermer la connec dans un finally.

Bien sympas comme retour d'expérience.
 
J'utilise souvent Try / Catch / Finaly pour tout ce qui est IDisposable avec des exécutions critiques.
Mais en générale j'essaye de me débrouiller sans, quand j'arrive sur les méthodes les arguments ont déjà été validé auparavant.
 
Par moments il peut m'arriver de faire des méthodes type TryNomDeLaMethode (Voir des méthodes d’extensions), mais là c’est plus spécifique au projet.
 
nucl3arfl0, as-tu des chiffres coté performances ? Car ce que tu viens de me dire m'intéresse beaucoup.
 
Fred82, oui j’ai cette option d’activé, c’est clairement utile, beaucoup plus simple lors du debug.
 
Taiche, exactement.

Des chiffres non, désolé.

Mais j'ai travaillé sur un produit qui a une interface où tu peux sélectionner des éléments à la souris. Si un élément sortait d'une zone limitée, une exception était levée (au sein d'un élément) et était gérée.
Ben je peux te dire que quand tu commençais à avoir beaucoup d'éléments sélectionnés, il n'appréciait pas trop.

J'avais fait un test comme ça pour voir, ben remplacé par un bonne vieille condition, c'était redevenu fluide.

Dans ces cas là, je préfère largement utiliser un using, c'est beauoup plus clair et concis et je suis sûr de pas m'emmeler les pédales.  
 
Sinon je suis plutot comme fred82, je n'utilise les try catch que dans des cas bien définis sinon je laisse les exception remonter.
 
A ce sujet, je recommande cet excellent article d'Eric Lippert:
http://blogs.msdn.com/b/ericlipper [...] tions.aspx

Ce n'est pas représentatif, les exceptions sont lourdes mais heureusement pas à ce point.
petit test effectué sur mon netbook:

var rnd = new Random();
var nbTemoin = 0;
var chronoTemoin = Stopwatch.StartNew();
for (var i = 0; i < 100000; i++)
{
    if (rnd.Next(9) < 5)
    {
        nbTemoin++;
    }
}
chronoTemoin.Stop();
 
var nbException = 0;
var chrono = Stopwatch.StartNew();
for (var i = 0; i < 100000; i++)
{
    try
    {
        if (rnd.Next(9) < 5)
        {
            throw new Exception();
        }
    }
    catch
    {
        nbException++;
    }
}
chrono.Stop();
 
MessageBox.Show(string.Format("Nb exception : {0}  Durée : {1}\r\nNb temoin    : {2}  Durée : {3}", nbException, chrono.Elapsed, nbTemoin, chronoTemoin.Elapsed));

Soit environ 90 microsecondes a chaque excepetion.

L''article est intéressant
 
Je préfère également les using, mais ça n'empêche pas l'utilisation des try/catch/finally dans certains cas.
D'ailleurs, quelqu'un en fait la remarque dans les commentaires dans l'article, il est difficile de lister toutes les exceptions que tu peux avoir.
 
En résumé, comme ça a déjà  été dit, c'est comme tout, il y a de bonnes et des mauvaises utilisations., mais de là à s'en passer, ce n'est pas un pas que je ferai.

Je vois pas comment utiliser un using dans le cas d'une connec à une BDD Parce que justement, c'est plutôt un truc de type fatal genre une requête qui se ramasse parce que la procédure stockée a changé de signature ou que sais-je. Là, t'as quand même envie de fermer la connec d'une part pour pas empirer les choses (par exemple, j'ai déjà vu un soft qui se connectait en boucle à la base, la connec était établie mais le serveur surchargé ne répondait pas suffisamment vite à la requête donc on se casse sans flinguer la connec et on revient X secondes plus tard ; je te raconte pas l'état du pool de connec et du serveur au bout d'1h) et d'autre part pour pas bloquer le client dans certains cas.
'fin ch'ais pas, j'ai effectivement utilisé using dans le cas de l'ouverture de fichier comme mentionné dans l'article, mais jamais pour une connec à une BDD.

Oui effectivement. L'utilisation de using n'est pas naturelle chez moi (je viens de Java ), donc j'ai tendance à l'utiliser seulement dans certains cas (fichier parce que c'est comme ça que j'ai appris mais aussi code managé), sans penser aux autres.

Ben oui, vu que la portée de la variable est celle du "try".

Voilà un exemple tout bidon.

Mon code ne génère pas d'exception.

Sinon, chouette blog celui d'Eric Lippert, merci marique
http://blogs.msdn.com/b/ericlipper [...] three.aspx Une bonne lecture

You made my day.

Malheureusement je travaille en équipe.

C'est facile de rejeter la faute sur les autres.

Règle d'or à retenir si on veux vite monter les échelons.

Tout à fait d'accord, mais ça peut aussi rester en tête, ce n’est pas bien de se mentir.

Tu peux dire ça de 90% des articles de son blog, c'est un des meilleurs blog de prog que je lis (si ce n'est le meilleur).

Tiens, par rapport a l'article d'au dessus , quelqu'un utilise "volatile" ? Je ne l'ai jamais utilise et j'ai du mal a y trouver une application

Bin justement, lis l'article

C'est une solution pour feignasse pour éviter d'avoir à gérer proprement l'interlocking sur les variables quand tu fais du multithread ou de l'IPC. En gros c'est moche mais ça marche bien la plupart du temps, jusqu'à ce que.

Ah ok
J'utilise généralement le lock ou les sémaphores selon le contexte, mais j'ai jamais entendu parlé de ce genre de truc

Je vois plus ça comme un outil bas niveau pour ceux qui comprennent vraiment de quoi ils parlent (c.a.d. pas nous).

Pas faux (et je n'ai pas de prétentions contraires pour ce qui est de mon niveau de maitrise de ces questions ). Cela dit, justement, les gens qui les comprenne comme Lippert ne semblent pas franchement en recommander l'utilisation .

Y a des gens qui utilisent le Framework Client Profile ?
 
Quel intérêt apporte-t'il principalement ?
 
Je pensais que ça permettait de déployer un client sans avoir à installer le framework (quitte à être plus limité), mais apparemment, il faut quand même installer le-dit framework.
Alors je me pose la question.

Ben après, ça dépend si c'est Visual Studio qui crée le setup, ou un logiciel tiers ?
 
Mais d'après ce que j'ai lu, il faut quand même l'installation d'un framework client profile pour que ça fonctionne.
Donc quitte à devoir installer un framework pour que ça marche, je me demande quel est son intérêt principal.

Je n'ai jamais eu l'occasion de l'utiliser, mais je sais qu'il existe.
 
On utilise beaucoup InnoSetup ici, pour le packaging, mais honnêtement, c'est vraiment à chier.

Salut les gars
 
J'ai besoin d'un coup de main à un niveau plus abstrait, je refait une partie du système de gestion des User de notre plateforme mais j'ai des doutes sur la conception.
 
Pour ce qui sera du code, toujours en (.Net) C# 3.5 (pas de MVC, Sql Server 2005 + PS)
 
Si vous avez une idée
 
http://forum.hardware.fr/hfr/Progr [...] 4774_1.htm

Et comme ça, ça te le fait aussi ?