j’ai un gros soucis. J’ai un System.StackOverflowException durant l’éxécution de mon appli ASP .NET. L’exception débarque au moment où je définis toutes mes variables SQLParameters avec les valeurs qui vont bien avant d’exécuter la procédure stockée qui va permettre de créer une nouvelle ligne. Au bout de la 72e valeur de mon tableau SQLParameters (parmis les 120), PATABOUM!
L’appli me met un message bien violent. J’ai pas trouvé de solution sur le web étant donnée qu’on est censé tomber sur cette exception dans des boucles infinis. Or, j’ai pas de boucles. Du coup, je vois pas comment le résoudre.
Edit : Le message que j’obtiens sous VS 2005 ->
Edit bis : Si c’est pas claire, voilà à quel endroit l’exception est déclenchée.
tu fais un get sur ta property, pas sur ton membre privé, donc tu t’appelles récursivement dans le vide, donc tu empiles tout sur la pile, donc tu fais péter la pile. change ça par le nom de ton membre privé en lowercase (je suppose), et ça resoudra le pb.
been there, done that… :crying:
(Allez metaldestro, dis nous que c’etait ça, on sait que t’as vu la réponse )
T’inquietes pas, cette erreur là, tu la feras 1 fois, pas 2 (j’en veux pour preuve que ça ne m’est jamais re-arrivé depuis que je l’ai faite aussi ). Par ailleurs, je remarque que tu utilises un _ devant ce que je pense etre tes membres privés, mais que ceux ci sont en Pascal Case (premiere lettre Upper). Il peut etre interessant de savoir que les Coding Rules / Guidelines / Whatever du C# recommandent les Pascal Casing pour les Properties (MaPropertyQueJeKiffe) et le camel casing (monMembreConcernéParLaPropertySusCitée) pour les membres.
De plus, suite a une discussion avec Styx31 sur IRC, il m’expliquait que le _ devant les noms de membres privés est une sorte de must have. Pourquoi ? Parce que les codings guidetrucs disent en gros que pour un membre privé correspond une property qui s’appelle pareil ou presque (enfin c’est souvent comme ça qu’on procede). De fait, tu auras monMembrePrivé et sa property MonMembrePrivé. Mais ça, c’est pas CLS compliant (vu que certains langage ne sont pas sensibles a la casse). D’ou le _ devant les noms de membres privés. l’avantage sera double : le camel case de ton membre privé et un _ devant te permettront d’eviter quasi a coup sur ce genre de couillade. (et ça sera CLS Compliant, joie)
Donc plutot que de trouver un nouveau nom pour chaque property, un petit _ evite de se retrouver avec des warnings de non CLS Compliantitude
[quote name=’“le MSDN”’]Characters and casing > All > CLS-compliant language compilers must follow the rules of Annex 7 of Technical Report 15 of the Unicode Standard 3.0, which governs the set of characters that can start and be included in identifiers. This standard is available from the Web site of the Unicode Consortium.
For two identifiers to be considered distinct, they must differ by more than just their case.[/quote]
http://msdn2.microsoft.com/en-us/library/12a7a7h3.aspx , j’invente rien hein. Apres j’ai découvert la justification des _ devant les noms de membres privés cet apres midi sur IRC. Je ne comprenais pas pourquoi tout le monde claquait ça devant les membres privés. Et pendant que je rédige ce post, en cherchant des echos sur le net, je découvre meme que des champs protected avec un _ en premier caractere ne sont pas CLS Compliant non plus. D’ou l’utilisation de “m_” par certaines coding guidelines.
Ben heu… ca dit juste qu’il faut qu’ils soient different par autre chose que par les majuscule/minuscules. Donc non, pas besoin de _ pour etre CLS compliant, je sais, j’en met pas, et pas de m_ non plus. C’est juste un truc que certaines personnes font pour rendre les choses pratiques de les distinguer par qqch de simple et consistant. C’est meme officiel, il n’y a pas de naming guideline pour le champs prives, tu les nommes comme tu veux du moment que c’est logique, si t’insiste je te trouve le numero de la page dans le “Framework Design Guidelines” :).
Apres de la meme maniere qu’on expose pas un champ en public directement, on fait une property, on expose pas un champ en protected non plus, donc la question ne se pose meme pas de savoir ce qui marche pour un champ protected, ca se fait pas quelle que soit la maniere dont c’est ecrit, avec un m_, un _ ou juste une minuscule :crying:.
On est completement d’accord, on se fout tous comme de l’an 40 de savoir comment les gens nomment leur variables (tant qu’on a pas a se taper la relecture du code hein). C’etait juste pour rester en accord avec son code a lui et « en général ». Parce que souvent on mets le meme nom, modulo le casing, sur les membres privés et leur property associée. C’est tout hein. J’ai pas dit que c’etait comme ça qu’il fallait faire absolument. J’ai pas été effectivement tres clair en disant « must have » et j’aurai du plutot employer un truc du style « toute différenciation explicite entre le nommage d’un membre privé et sa property est un must have pour eviter les merdouilles avec le CLS ». C’est mieux ?
EDIT : de plus, une différenciation plus marquée dans le nommage permet de reperer / eviter plus facilement ce genre d’erreur un peu chiante (développeur feignant, on valide trop vite l’intellisense et zoup, on se prend un bon gros stack overflow sur un appel recursif infini). Comme dit plus haut, je l’ai faite cette connerie là, et perdre 30 minutes a chercher en vain pour une bete question de casing, c’est sacrément frustrant. . C’est juste ça hein.
Ben, t’as le droit de slapper le gars qui a ecrit ca (surtout qu’avec resharper, ca se fait tout seul :)) Et en retour, il risque de te slapper pour pas avoir compris plus vite d’ou venait le probleme. Donc, a ce moment la, tu auras le droit de le reslapper pour avoir ecrit du code moisi, mais il risque de te slapper en retour pour pas avoir compris plus vite d’ou venait le probleme, mais dans ce cas la, tu auras le droit de le slapper pour avoir ecrit du code bidon, mais a ce moment la <— PIOUUUUUU STACK OVERFLOW —>
)