Discussion :

[neo.51]

On peu considérer ça comme un 'racourcis'

N'empèche que c'est bien pratique ce using

[Moonheart]

On peu considérer ça comme un 'racourcis'

Ben je crois que c'est la définition même d'une macro.... non?

[neo.51]

autant pour moi j'avais zappé ton post

[Maniak]

Je ne suis pas sur que ce mot-clef soit une fonctionalité à part entière... a vue d'oeil ca m'a plutot l'air qu'une macro.

Pas vraiment. L'équivalent en VB.NET serait un truc du genre

Code :

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

1
2
3
4
5
6
Try
  Dim toto As tutu
  blah blah blah
Finally
  toto.Dispose()
End Try

et il y a une bonne chance pour que le using de C# ne se trimballe pas l'overhead d'un try/catch, vu qu'une fois sorti du contexte 100% géré par le GC (ce que le compilo peut faire), on peut obtenir cette fonctionnalité très facilement.

Donc j'aurais tendance à dire que c'est une fonctionnalité à part entière du C# qui permet de retrouver un bout de fonctionnalité qu'on perd par rapport au C/C++ avec l'intervention du GC (la prévisibilité de l'instant de destruction des objets).

[Moonheart]

Je ne vois pas très bien ce que le try-catch viens faire la dedans...

Pour moi l'equivalent serait plutot:

Code :

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

1
2
3
4
 
  Dim toto As tutu 
  blah blah blah 
  toto.Dispose()

non?

[Maniak]

Je ne vois pas très bien ce que le try-catch viens faire la dedans...

Pour moi l'equivalent serait plutot:

Code :

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

1
2
3
4
 
  Dim toto As tutu 
  blah blah blah 
  toto.Dispose()

non?

Ben non.
Si tu as une exception balancée dans la partie blah blah blah, ton Dispose() n'est jamais appelé. Si tu as un return au milieu, idem.

using assure que Dispose() est toujours appelé, quoi qu'il arrive. Et la seule façon de reproduire ça en VB.NET, c'est avec un Try/Finally.

[Moonheart]

En même temps, si une exception se produit dans ton using et que tu ne l'as pas catchée, c'est que ton code n'est pas propre...

Il devrait toujours y avoir un try-catch autour d'une fonction pouvant renvoyer une exception et si tu le met, alors le gain du "using" est nul.

[Maniak]

En même temps, si une exception se produit dans ton using et que tu ne l'as pas catchée, c'est que ton code n'est pas propre... ;)

Il devrait toujours y avoir un try-catch autour d'une fonction pouvant renvoyer une exception et si tu le met, alors le gain du "using" est nul.

Ça c'est une théorie un peu extrêmiste jamais mise en oeuvre :)
Surtout dans .NET ou plus d'une fonction sur deux dans le runtime est susceptible de balancer plusieurs exceptions :)

Si tu veux vraiment coller des try/catch partout où une exception peut être lancée, à tous les niveaux du code, non seulement ça va donner du code imbitable, mais bonjour les ralentissements (un try/catch, c'est loin d'être gratuit).

Quand tu fais la moindre requête, tu fais un try/catch pour gérer le cas où le serveur SQL est saturé et fait un timeout ? :)


Les exceptions n'ont pas eu leur nom pas hasard. Elles ne sont pas censées arriver fréquemment, et on n'est censé chercher à les intercepter que quand c'est vraiment critique. Pas à la moindre occasion.
Tu ne fais pas un try/catch pour la moindre opération sur une chaine de caractères. Tu en fais un sur le module entier si vraiment il y a un risque qu'une exception soit balancée. Y a des limites :)

[Moonheart]

Quand tu fais la moindre requête, tu fais un try/catch pour gérer le cas où le serveur SQL est saturé et fait un timeout ?

Bien entendu !
Je vais pas aller faire crasher le logiciel juste parce que si sa se trouve y'a un problème dans un cable réseau menant au serveur SQL... L'utilisateur n'a probablement pas envie de perdre tout le travail qu'il a fait dessus pour un problème qui sera résolu sous peu par les authorités compétentes.

Les exceptions n'ont pas eu leur nom pas hasard. Elles ne sont pas censées arriver fréquemment, et on n'est censé chercher à les intercepter que quand c'est vraiment critique. Pas à la moindre occasion.
Tu ne fais pas un try/catch pour la moindre opération sur une chaine de caractères. Tu en fais un sur le module entier si vraiment il y a un risque qu'une exception soit balancée. Y a des limites

Oui ben j'aimerais pas être le mec de la hotline qui va recevoir le coup de fil en ton absence d'un utilisateur qui demandera pourquoi le programme que tu as concu plante en lui balancant des messages d'insultes sans qu'on saches pourquoi...

Une erreur, ca se traite. Point final.
On laisse pas des exceptions se balader comme ca dans la nature!!! Si une fonction de timeout dit qu'elle peux balancer une exception c'est justement pour que les programmeurs puissent faire de la reprise sur erreur. PAS pour le programme crashe plus rapidement.
La dernière erreur non-traitée dans un code à la Nasa a couté une fusée spatiale et toutes les vies humaines qu'elle transportait, je le rappelles quand quand même...

Je rappelles que les exceptions ne sont pas un mécanisme fait pour permettre aux programmeur d'éviter d'avoir à écrire des code de reprise sur erreur, mais un mécanisme fait pour les y aider.

[Maniak]

Quand tu fais la moindre requête, tu fais un try/catch pour gérer le cas où le serveur SQL est saturé et fait un timeout ? :)

Bien entendu !

Ok, donc à chaque fois que tu appelles la méthode Open d'une connexion, tu fais un try/catch pour InvalidOperationException et SqlException, puis quand tu fais un ExecuteNonQuery, tu fais un try/catch pour SqlException, quand tu récupères un élément d'un DataReader, tu fais un try/catch pour IndexOutOfRangeException (idem pour toutes les collections d'ailleurs), quand tu fais un Add dans un ArrayList, tu fais un try/catch pour NotSupportedException ?

Si tu as une méthode qui fait 10 requêtes SQL, tu vas faire un try/catch sur chaque au cas où il y ait un problème sur le serveur, au lieu de simplement en faire un au niveau de la méthode dans son ensemble ?

Ben dis-donc, faut aimer perdre du temps pour rien.

Oui ben j'aimerais pas être le mec de la hotline qui va recevoir le coup de fil en ton absence d'un utilisateur qui demandera pourquoi le programme que tu as concu plante en lui balancant des messages d'insultes sans qu'on saches pourquoi...

Une erreur, ca se traite. Point final.

Parce que pour toi, si on n'intercepte pas *toutes* les exceptions au niveau le plus bas possible, c'est forcément qu'on ne les traite jamais ?
On n'a pas le droit de les intercepter à un niveau plus élevé parce que quel que soit l'endroit où une exception peut se produire dans un traitement donné, c'est le traitement dans son ensemble qui est mis en cause ?

La dernière erreur non-traitée dans un code à la Nasa a couté une fusée spatiale et toutes les vies humaines qu'elle transportait, je le rappelles quand quand même...

Ça commence à me brouter ce retour là-dessus pour justifier tout et n'importe quoi. Tu as vu le code ? Tu étais sur place ? Tu sais *exactement* ce qui s'est passé ? Tu sais que tout a été causé par un try/catch qui manquait ? Non ? C'est juste une supposition ? Alors évite.

Je croyais que tout ça avait été causé par l'utilisation de la POO ? On m'aurait menti ? En fait ça a été causé par la non-utilisation de try/catch ? Mince alors.

Je rappelles que les exceptions ne sont pas un mécanisme fait pour permettre aux programmeur d'éviter d'avoir à écrire des code de reprise sur erreur, mais un mécanisme fait pour les y aider.

Yup, mais pas pour les obliger à coder un mécanisme de reprise sur erreur à chaque instruction. Encore heureux.


Bon, je sais pas pourquoi, je sens que ça va repartir en pinaillage sur le sens caché des mots... Si c'est le cas, rendez-vous au prochain sujet (ou à une intervention tierce).

[bidou]

Je suis d'autant plus d'accord avec ce que viens de dire maniak que faire de la gestion systématique revient souvent à ne pas en faire.
Car ou tu cherches à identifier clairement l'exception pour la traiter et éviter l'arrêt mais il est impossible de faire de la gestion sur chaque ligne sauf à ecrire 25000 lignes pour gérer une pendule, ou c'est juste pour dire à l'utilisateur "aïe, y a un boulon dans le potage" et comme de toute façon ca va planter, ca ne sert à rien.

Un des intérêt du code managé est justement de ne pas percuter le système lors d'une erreur.

[Moonheart]

Ok, donc à chaque fois que tu appelles la méthode Open d'une connexion, tu fais un try/catch pour InvalidOperationException et SqlException, puis quand tu fais un ExecuteNonQuery, tu fais un try/catch pour SqlException, quand tu récupères un élément d'un DataReader, tu fais un try/catch pour IndexOutOfRangeException (idem pour toutes les collections d'ailleurs), quand tu fais un Add dans un ArrayList, tu fais un try/catch pour NotSupportedException ?

Si tu as une méthode qui fait 10 requêtes SQL, tu vas faire un try/catch sur chaque au cas où il y ait un problème sur le serveur, au lieu de simplement en faire un au niveau de la méthode dans son ensemble ?

Ben dis-donc, faut aimer perdre du temps pour rien.

Mmm je crois que tu oublies un peu l'un des principes même de la programmation objet, c'est à dire la réutilisabilité du code!
JAMAIS je n'utilise les fonction Open ou ExecutNonQuery directement dans un programme! J'ai crée une classe "Database" qui possède des méthodes équivalentes et qui font appel à ces fonctions à l'intérieur de try/catchs et gèrent leurs erreurs.

Ca je l'ai fait UNE fois dans mes 3 dernières années de développement, et depuis j'ai plus jamais réécrit les try/catchs des fonctions que tu cites... Pourquoi faire puisque mon objet Database s'en charge? Il récupère les erreurs, les analyses fait ce qu'il faut si nécessaire pour relancer l'opération convenablement si possible, affiche les message d'erreurs si besoin et renvoie au bout du compte un objet "Resultat" ... de temps en temps j'etoffe un peu la mécanique, mais je ne récris jamais la totalité de l'ensemble a chaque éxécution de ces méthodes.

Parce que pour toi, si on n'intercepte pas *toutes* les exceptions au niveau le plus bas possible, c'est forcément qu'on ne les traite jamais ?
On n'a pas le droit de les intercepter à un niveau plus élevé parce que quel que soit l'endroit où une exception peut se produire dans un traitement donné, c'est le traitement dans son ensemble qui est mis en cause ?

Si tu mets ta gestion erreur plus haut alors tu sors de la fonction, donc la référence de l'objet est perdue et donc le garbage collector se charge de l'affaire.... et donc l'utilisation du using devient obsolète.

Les mécaniques de style "using" c'est surtout utile en C++... en .net ca l'est nettement moins.

Ça commence à me brouter ce retour là-dessus pour justifier tout et n'importe quoi. Tu as vu le code ? Tu étais sur place ? Tu sais *exactement* ce qui s'est passé ? Tu sais que tout a été causé par un try/catch qui manquait ? Non ? C'est juste une supposition ? Alors évite.

Essayons quand même de rester calme et courtois, si possible... Ce n'est qu'une discussion, si tu veux connaitre les sources d'une personne, il suffit de les demander poliment, pas la peine d'insinuer qu'elle invente à fur et à mesure...

Dans le cas présent, l'information est issue d'un article officiel issu d'une interview avec un responsable de l'enquête de la Nasa... C'est d'ailleurs devenu un cas d'école depuis.

Je croyais que tout ça avait été causé par l'utilisation de la POO ? On m'aurait menti ? En fait ça a été causé par la non-utilisation de try/catch ? Mince alors.

Ca... je n'en sais rien, je ne sais pas d'où tu sors cette information.
Toutefois même si l'erreur de base à été causée par la POO comme tu le prétends, cette erreur n'AURAIT PAS causé la destruction de la fusée si les exceptions avaient toutes été catchées comme il convient...

Après tout, ce n'était qu'un problème de dépassement binaire, c'est pas la mer à boire en général.

Bon, je sais pas pourquoi, je sens que ça va repartir en pinaillage sur le sens caché des mots... Si c'est le cas, rendez-vous au prochain sujet (ou à une intervention tierce).

Je trouves que tu te commences à te montrer foncièrement désagréable dans cette discussion. Quand on débat de quelque chose, avoir une sémantique claire est il me semble important... cela évite les dialogues de sourds. Si ca te déplait, c'est ton droit, mais ce n'est pas une raison pour te montrer hautain ou condescendant à ce propos.

Gardons une bonne ambiance à ce thread et à ce forum, c'est la meilleure chose à faire

[Maniak]

Je trouves que tu te commences à te montrer foncièrement désagréable dans cette discussion. Quand on débat de quelque chose, avoir une sémantique claire est il me semble important... cela évite les dialogues de sourds. Si ca te déplait, c'est ton droit, mais ce n'est pas une raison pour te montrer hautain ou condescendant à ce propos.

Désagréable, ça oui, c'est un effet secondaire d'être de mauvais poil à cause du taf :)
Hautain et condescendant, là non, c'est surtout un fort désintérêt pour les coupages de cheveux en 4.

Et dans ce domaine de coupage de cheveux en 4, ton principe de gérer les erreurs au niveau le plus bas se pose bien là.

Au niveau de ton objet Database, tu sais quoi faire remonter à l'interface de ton appli quand il y a un problème ?
Moi non. Mon objet Database (oui, j'en ai un aussi, je n'ai pas oublié l'un des principes même de la programmation objet :) est utilisé par une couche elle-même utilisée par une autre couche qui elle s'occupe de l'interface utilisateur, et ce aussi bien pour des applis Win que Web. Si une exception est lancée par l'accès à la BDD dans la couche la plus basse, il n'y a aucun moyen de la gérer correctement dans le contexte de son appel... tout bêtement parce qu'il n'y a aucun moyen de savoir dans quel contexte la fonction plantée a été appelée. Comment demander l'avis de l'utilisateur quand on ne sait même pas s'il utilise une appli win, s'il est sur une page web, ni même s'il y a un utilisateur ou s'il s'agit d'une tâche automatisée ?

Là c'est surtout toi qui a oublié un des principes même des exceptions : la propagation. Si tu ne connais pas le contexte d'exécution d'une méthode lançant une exception, tu la propages pour les niveaux supérieurs, et ainsi de suite jusqu'à arriver à un niveau qui saura quoi faire.

Il n'y a pas de problème d'objets inaccessibles ou quoi que ce soit, vu que les objets nécessaires sont propagés dans l'exception elle-même.

Exemple tout bête : il n'y a aucune raison de gérer les exceptions d'accès concurrentiel dans la fonction qui appelle DataAdapter.Update. Ça ne sert à rien, tu ne sais pas en quoi consiste la mise à jour. Ce n'est qu'à un niveau supérieur que tu peux décider de la meilleure chose à faire. Que ce soit forcer la mise à jour, demander l'avis de l'utilisateur (en lui fournissant des infos que tu n'as qu'à ce niveau), etc.

Chercher à gérer la moindre exception à tout prix au niveau le plus bas possible, c'est une perte de temps assez monumentale (pour peu que l'application soit un minimum complexe) et comme le dit si bien bidou, ça revient souvent à ne pas faire de gestion d'erreur du tout.

Gérer une erreur de manière 'générique', sans avoir les éléments pour agir correctement, juste pour le principe de la gérer là, tout de suite, c'est pas forcément, et très certainement bien pire que de ne pas la gérer du tout. Ça reviendrait à masquer des problèmes à un niveau supérieur.

À moins bien sûr que ta méthode consiste à propager l'exception dans tous les cas, mais en faisant un petit traitement à chaque étape quand même. Genre "bon ben là y a eu une exception, je ne sais pas bien quoi faire avec donc je la renvois à qui voudra, mais je marque quand même qu'elle s'est produite. ça ne sert à rien, mais ça fait plaisir."


Et comme pour les histoires de machines virtuelles et de runtime, je n'aborderai plus ce sujet dans ce thread, qui devient décidément très éloigné de son sujet initial. Si tu veux poursuivre la discussion sur ce sujet, pas de problème, mais fais le dans un nouveau thread. Ça c'est un des principes même d'un board : un sujet par topic (ah ben tiens, ça veut dire sujet aussi, drôle de hasard :)

Dans un forum je ne dis pas, mais dans un board, non :)

[Moonheart]

Joli discours, mais qui repose sur une pure invention de ta part, à savoir celle-ci:

ton principe de gérer les erreurs au niveau le plus bas se pose bien là.

Désolé, mais je n'ai jamais prétendu avoir un tel principe.

[Maniak]

Allez, une dernière pour la route :

Joli discours, mais qui repose sur une pure invention de ta part, à savoir celle-ci:

ton principe de gérer les erreurs au niveau le plus bas se pose bien là.

Désolé, mais je n'ai jamais prétendu avoir un tel principe.

1)

Il devrait toujours y avoir un try-catch autour d'une fonction pouvant renvoyer une exception et si tu le met, alors le gain du "using" est nul.

2)

Quand tu fais la moindre requête, tu fais un try/catch pour gérer le cas où le serveur SQL est saturé et fait un timeout ?

Bien entendu !

Bon alors maintenant tu m'expliques :

Choix no1 :
Tu as pour principe de mettre un try/catch partout où il y a un risque d'exception, ce qui est non seulement de l'overkill mais aussi une mauvaise pratique (parce que rarement moyen de gérer proprement une erreur au niveau le plus bas). Dans ce cas mon 'discours' ne se repose pas sur une invention, mais bien sur ce que tu dis.

Choix no2 :
Tu fais comme "tout le monde", à savoir intercepter les exceptions que tu peux gérer, au niveau où tu sais comment les gérer. Auquel cas tes commentaires initiaux sont très mal formulés et tes démonstrations & leçons de design mal placées vu que c'est exactement ce que je dis depuis le début.

Ce qui, pour en revenir au cas du 'using', rend tout à fait valide l'utilisation d'un 'using' assurant que Dispose est appelé quoi qu'il arrive, même si une exception est lancée, exception qui ne serait pas forcément interceptée au niveau du 'using' si on ne se trouve pas à un niveau permettant de la gérer.

Autrement dit si, 'using' a bien une utilité évidente, non-disponible en VB.NET, vu qu'on n'est pas forcés de gérer toutes les exceptions là où on fait ce fameux 'using'.



C'est quoi la bonne version ?

Note bien que je n'essaye pas d'être désagréable hein. Moi j'ai compris tes commentaires initiaux comme "oula mais ne pas gérer toutes les exceptions partout où elles peuvent être lancées, c'est minable comme façon de développer". Si c'était bien ça, ma réaction est justifiée. Sinon non, mais dans ce cas, je me demande pourquoi tu as critiqué ce que tu trouves normal et appliques toi aussi.

[neo.51]

Bon, je pense que vous m'avez fait assez de posts hors sujet comme ça tous les deux

Vos interventions sont trés intéréssantes mais le problème c'est qu'on s'évade du sujet.

Si vous souhaitez vous pouvez créer d'autres thread pour lancer des débats sur la compilation JIT, sur la gestion des exceptions, etc... si les débats sont intéréssant je les passerais en post-it

Mais ici restons dans le C# VS VB.NET qui doit interéssé toute personne désirant se mettre à .NET

Le débat est cloturé le temps que que je nettoie vos bétises

Réouverture du thread une fois que le ménage aura été fait


pour votre participation

[Babylon]

Salut,

dans le boite où je travaille, nous pensons à migrer vers une solution .Net / Mssql server. Et forcément nous sommes arriver à la question du choix du langage. Il faut savoir que les premiers développement serait un ensemble de classe interne à la boite ("extension" du framework, abus de langage ?) puis développement de 2 clients lourds (pas de développement web prévu pour le moment).

J'ai donc chercher les différences qui seraient (il est tout à fait possible que j'en ai oublié):
C# :
gestion de la doc XML
mot clef using
Possibilité de désactiver le dépassement de capacité
présence des types non signés
VB .Net :
Option explicit (activable/desactivable)
Option scrict (activable/desactivable)

et donc la question finale (en sachant que la plupart des développeurs chez nous ont un profil plutôt VB), est-ce que le fait de ne pas avoir la doc XML et le mot clef using est un réel manque en VB .net ?

merci d'avance

PS : si vous connaissez d'autre(s) différence(s) ça serait sympa de m'en faire part

[Fusion de deux messages - Message d'origine nettoyé]
[edit du à la fusion]
Je demande si les quelques fonctionnalités que j'ai repérées dans C# et qui ne semblent pas être dans Vb .net sont vraiment pénalisantes si on ne les a pas.
[/edit]

[Keihilin]

Using

Ben c'est d'une utilité "pratique" indéniable, mais il y a des centaines de projets en VB qui s'en passent allégrement.

Doc XML

De mon point de vue, c'est un manque important de VB.net. Même si il y a des outils qui peuvent en partie palier ce manque (VBCommenter), leur intégration à VS.net est beaucoup moins bonne.

[Piotrek]

1) personnellement en tant que ancien chef, je pense tout d'abord a l'impact economique de la decision, si comme moi tes collegues sont des purs VB, je conseille de passer a vb.net a moins d'etre pret a encaisser un mois de chute de productivite spectaculaire.
J'ai commence par C#, et puis par curiosite j'ai tente vb.net

My life in ze post:
http://www.developpez.net/forums/vie...25019&start=30

-> Pour les commentaires xml aucun pb, pour vb ils sont disponibles avec les powertoys pour visual studio.net

http://www.gotdotnet.com/team/ide/

et seront inclus dans le prochain visual studio.

2) Je dev aussi des clients lourds pour base de donnee et je n'ai trouve aucune difference entre les deux languages quant a cet usage. Il se peut que C# a l'avenir recoive des fonctionnalites supplementaitres qui devraient concerner des aspects objets tres specifiques (je pense aux types partiels) qu'a mon avis je n'utiliserais jamais dans un client de base de donnee.

3) Using c'est pas Imports en vb.net?

4) "extension" du framework, abus de langage ? << non

5) avantage a vb.net: c'est aussi le language de macro de vs.net (sympa pour lancer ses generateurs de classes et mechaniser votre extension de framework)

6) Microsoft.VisualBasic aide a migrer en douceur le temps de s'adapter au reste du framework

Si t'as d'autres questions quant a la migration, hesite pas

[Babylon]

3) Using : il y a deux type de using, le premier c'est l'imports de VB .Net. Pour l'autre jète un oeil là

Personnellement je suis plus beaucoup plus pour la syntax du C# (avis personnel) mais je vais devoir me plier devant le choix du plus grand nombre vu que les autres sont purs VB.

Merci pour ta réponse claire et précise, c'est juste ce qu'il me fallait.