Version imprimable
Salut,
Je suis souvent confronté à
J'ai du mal à comprendre pourquoi nous n'avons pas droit d'écrire directement :Code:
2
Il doit certainement y avoir une raison et j'aimerais bien la connaitre si quelqu'un est au courant.Code:
2
D'avance merci pour votre réponse
Laurent
C'est que le type de la colonne pour ta table n'est pas un type int.
Au risque de dire des bêtises lol, le Parse étant réservé au string (conversion de sting à int), pour convertir un Object en un int tu dois soit utiliser Convert (si t'es sûre que ton objet n'est pas nulle) soit passer par un string ...
Quelqu'un pour confirmer ou infirmer ?
Je vois... D'un autre côté générer une exeption si on se plante de colonne ça me parait plus sûr que d'utiliser un toString qui marche quasiement à tous les coups...
D'autres avis seraient les bienvenus
Laurent
Pour ma part, je vois deux techniques différentes: du parsing et du casting. On aurait encore pu ajouter de la conversion... :-)
Dans le cas que tu cites, moi j'aurais utiliser un TryParse() et affecter une valeur valide par défaut dans le cas d'un parsing raté. Je préfère afficher un résultat valide même s'il ne correspond pas à ce que l'utilisateur attend plutôt qu'une application plantée avec une exception. Mais il faut voir le cas d'utilisation.
Si ta colonne n'est pas un int, toString va fonctionner mais le Int.parse va lancer une exception.Citation:
Envoyé par Laurent Jordi
+1 pour la solution made in neptune ;)
L'objet de la présente discussion n'est pas tant de dire ce que l'on aurait fait mais plutôt comment on expliquerait à son client si ce qu'il a fait est une bonne pratique ou un raccourcis dangeureux.
Quoi qu'il en soit, merci pour vos avis
Laurent
En t'expliquant ce que j'aurais fait tu peux comparer avec les méthodes dudit client et voir si ces pratiques sont dangereuses. J'ai témoigné sur ma méthode, à toi de construire l'argumentation.Citation:
Envoyé par Laurent Jordi
Ce raisonnement me paraît fort dangereux...Citation:
Envoyé par neptune
Quelle que soit la stratégie (int.Parse, Convert.ToInt...) il me paraît primordiale qu'une exception soit levé si les données ne sont pas du bon type.
Non, ca dépend, c'est pour cela que j'ai précisé qu'il faut voir le cas d'utilisation.Citation:
Envoyé par Keihilin
Par exemple: j'offre à ton utilisateur la possilbité d'entrer le nom d'un champ sur lequel il trie son gridview. Je préfère laisser le gridview affiché, avec le tri précédent et afficher un message non invasif lui signifant son erreur plutôt que sortir l'artillerie de l'exception, le gros message d'erreur style fenetre modal, etc.
OK, je caricature, mais c'est pour bien imager.
En l'occurence il s'agit plutôt de développeurs peu attentifs, rien de générique. "Si le type n'est pas bon on le verra bien à la recette..." Je n'aime pas trop ce genre de raisonnement car une fois que ça plante on se retrouve en situation de crise et les délais explosent...
La c'est un cas basique mais le projet dont je parle est truffé de trucs comme ça.
Genre, au lieu d'appeler les SQL Command avec les outils SQL Clients en passant proprement les paramètres, ils préfère construire la chaine d'execution de la requete sous forme de string genre :
"Exec monShema.MaProc Param1,Param2,...,ParamN"
Si on change une procedure stocké, ça peut ne pas planter mais renvoyer n'importe quoi.
++
Laurent