comparaison de types

Bonjour,

J'aimerai écrire une fonction qui prend en entrée un objet, et qui sort la valleur nulle si l'object est à une certaine valeur du type:

En gros:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

private object specialConvert(object o) { if (o.Type == Int32) { int i = (int)o; if (i == int.MinValue) { return null } } else if (o.Type == string) { string s = (sting)o; if (i == string.Empty) { return null } } return o; }

---

Merci :)

plusieurs moyens

if gettype(o) is string


ou encore faire une fonction générique
et tester le type fourni

Pour information c'est une mauvaise pratique de renvoyer des objets null (cela évite des erreurs types référence objet inconnu etc..) à la rigueur il faudrait renvoyer une exception genre Int32MinValueException.

Il suffit d'utiliser l'opérateur is :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

private object specialConvert(object o) { if (o is Int32) { int i = (int)o; if (i == int.MinValue) { return null; } } else if (o is string) { string s = (string)o; if (i == string.Empty) { return null; } } return o; }

---

Citation:

---

Envoyé par hegros

Pour information c'est une mauvaise pratique de renvoyer des objets null

---

Tu as vu ça où ? Si c'est une mauvaise pratique, c'est sûrement la plus répandue au monde... Si la méthode est correctement documentée et qu'il est clair qu'elle peut renvoyer null, je ne vois pas où est le problème. Ca ne causera pas de NullReferenceException si l'appelant vérifie correctement la valeur de retour. D'ailleurs qui te dit que le fait de renvoyer null dans cette méthode signifie qu'il y a une erreur ?

Les exceptions c'est bien, mais faut pas en abuser... C'est très pénalisant en termes de performances. D'ailleurs, utiliser des exceptions pour faire du contrôle de flux, pour le coup, est unanimement considéré comme une mauvaise pratique. Les exceptions, comme leur nom l'indique, servent à gérer des situations exceptionnelles. Le fait d'avoir un entier égal à Int32.MinValue ou une chaine vide peut difficilement être considéré comme une situation exceptionnelle...

Citation:

---

Envoyé par tomlev

Tu as vu ça où ? Si c'est une mauvaise pratique, c'est sûrement la plus répandue au monde...

---

Dans le livre Code Propre. Et oui il y a pleins de mauvaises pratiques répandues dans le monde...Je rigole parce que parfois certains te répondent "oui mais en c++ on fait comme cela tout le temps" comme si en C++ tu ne pouvais pas avoir de mauvaises pratiques.

Citation:

---

Envoyé par tomlev

Si la méthode est correctement documentée et qu'il est clair qu'elle peut renvoyer null, je ne vois pas où est le problème. Ca ne causera pas de NullReferenceException si l'appelant vérifie correctement la valeur de retour. D'ailleurs qui te dit que le fait de renvoyer null dans cette méthode signifie qu'il y a une erreur ?

---

Personnellement aussi je trouve que c'est une mauvaise pratique tu te retrouves avec du code spaghetti à tester partout si ton objet n'est pas nul alors qu'un objet même vide éviterez de faire des if object!=null partout dans le code. Pis je n'ai jamais dis que renvoyer nul signifiait une erreur mais souvent c'est pour lever une exception...

Citation:

---

Envoyé par tomlev

D'ailleurs, utiliser des exceptions pour faire du contrôle de flux, pour le coup, est unanimement considéré comme une mauvaise pratique.

---

1/ Quelles références ? Qui représente l'unanimité ? (j'ai cité code propre pour ma part)
2/Où dans le code posté il est question de contrôle de flux ? C'est une fonction de conversion(specialconvert)

Citation:

---

Envoyé par tomlev

Les exceptions, comme leur nom l'indique, servent à gérer des situations exceptionnelles. Le fait d'avoir un entier égal à Int32.MinValue ou une chaine vide peut difficilement être considéré comme une situation exceptionnelle...

---

Cela dépend du contexte. Une chaîne vide peut être considérée comme une exception s'il s'agit d'une chaîne pour identifier un équipement dans un réseau par exemple. De même que Int32.MinValue ou tout ce que l'on peut imaginer

Citation:

---

Envoyé par hegros

1/ Quelles références ? Qui représente l'unanimité ? (j'ai cité code propre pour ma part)

---

MSDN par exemple :

Citation:

---

Do not use exceptions for normal flow of control, if possible

---

J'ai pas cherché plus loin, mais il doit y en avoir pas mal d'autres... En tous cas c'est l'opinion largement majoritaire (peut-être pas unanime, je te l'accorde) de la communauté, on s'en rend vite compte en se promenant sur les forums

Citation:

---

Envoyé par hegros

2/Où dans le code posté il est question de contrôle de flux ? C'est une fonction de conversion(specialconvert)

---

Oui, justement. Une fonction de conversion qui doit renvoyer null dans certains cas. Si c'est la valeur que tu veux obtenir, ça n'a pas de sens de lever une exception... Intercepter une exception plutôt que de tester la valeur de retour, c'est une forme de contrôle de flux par les exceptions : au lieu de faire un if/else, tu fais un try/catch. Même si au final, ça va revenir au même, le try/catch sera juste beaucoup plus lent...

D'autre part, si tu sais qu'une exception peut se produire et que tu sais sous quelles conditions elle se produit (ce qui est le cas ici), tu t'arranges pour vérifier les valeurs avant de façon à éviter l'exception.

je ne suis pas pour écouter ce qui est dit, je préfère réfléchir

par exemple certains disent qu'il vaut mieux avoir un point de sortie unique dans une fonction
mais faire des if condition exit sub (break je crois en c#) ca permet parfois de ne pas imbriquer 20 if et donc de lire le code plus facilement

personnellement retourner des null ca me dérange pas non plus, et je le précise dans l'aide xml d'appel de la fonction

Citation:

---

Envoyé par tomlev

J'ai pas cherché plus loin, mais il doit y en avoir pas mal d'autres... En tous cas c'est l'opinion largement majoritaire (peut-être pas unanime, je te l'accorde) de la communauté, on s'en rend vite compte en se promenant sur les forums

---

Pour ma part renvoyer des objets nuls c'est travailler à l'ancienne comme on faisait à l'époque en C parce qu'il n'y avait pas(et toujours pas encore et probablement jamais) de support des exceptions.

Je suis assez curieux de savoir d'où tu tiens cette opinion soit disant majoritaire.

Citation:

---

Oui, justement. Une fonction de conversion qui doit renvoyer null dans certains cas. Si c'est la valeur que tu veux obtenir, ça n'a pas de sens de lever une exception...

---

Si c'est la valeur que tu veux obtenir cela n'a pas de sens non plus de renvoyer nul...

A la lecture du code j'en déduis qu'il renvoit nul dans des cas exceptionnels donc les exceptions ont tendance à montrer leur bout du nez.

Citation:

---

Intercepter une exception plutôt que de tester la valeur de retour, c'est une forme de contrôle de flux par les exceptions : au lieu de faire un if/else, tu fais un try/catch. Même si au final, ça va revenir au même, le try/catch sera juste beaucoup plus lent...

---

Travailler avec des codes d'erreur plutôt que des exceptions c'est travailler à la C. D'ailleurs dans le lien que tu donnes de msdn c'est dit que dans le framework cela ne travaille pas avec des codes retour mais des exceptions.

Bref, si le posteur est heureux de travailler avec des objets nuls et de tester partout si l'objet n'est pas nul tant mieux. La solution est bien d'utiliser le mot clef is cependant je vais encore chipoté mais ce code à au moins 2 défauts de conceptions :

1/Il fait des traitements en fonction du type.
2/Le code n'est pas OCP.

Citation:

---

Envoyé par hegros

Je suis assez curieux de savoir d'où tu tiens cette opinion soit disant majoritaire.

---

C'est juste une opinion que j'ai souvent vue exprimée sur des forums ou sites de Q/R (Stackoverflow notamment), par des gens dont les compétences sont reconnues, et les autres participants approuvaient largement. Je n'ai pas de "preuve formelle" que c'est l'opinion majoritaire, donc je n'insisterai pas là-dessus...

Je ne dis pas que c'est la vérité absolue, mais personnellement je suis d'accord avec ce principe. Après, libre à toi de faire autrement...

Citation:

---

Envoyé par hegros

Si c'est la valeur que tu veux obtenir cela n'a pas de sens non plus de renvoyer nul...

---

Si je veux obtenir null ça n'a pas de sens de renvoyer null ? Là je ne te suis plus :koi:

Citation:

---

Envoyé par hegros

A la lecture du code j'en déduis qu'il renvoit nul dans des cas exceptionnels

---

Ben moi j'en déduisais plutôt que null était le résultat de la conversion dans ces cas là... c'est une question d'interprétation. De toutes façons on ne sait pas ce qu'il veut faire, essayer de le deviner relève de la pure spéculation.

Citation:

---

Envoyé par hegros

Travailler avec des codes d'erreur plutôt que des exceptions c'est travailler à la C

---

Qui a parlé de code d'erreur ? Tel que j'interprète son code, renvoyer null ne signifie pas qu'il y a eu une erreur, et null n'est donc absolument pas un code d'erreur, c'est juste la valeur de retour de la méthode.

Evidemment s'il y a lieu de signaler une erreur, j'utilise des exceptions, pas des codes d'erreurs ;)

mouais il faut dire que je ne considère pas nul comme une valeur comme les autres. C'est une valeur particulière d'ailleurs il écrit en bleu dans l'éditeur pour toujours se le rappeler et il y'a même un opérateur spécial(?) pour spécifier les variables acceptant cette valeur :aie:

Après si tu regardes dans le framework, les méthodes de conversion renvoient en général une exception et pas nul sauf pour les variantes TryConvertXXX mais bon je m'avance peut être un peu là.

Pour revenir au code, tu n'es pas d'accord qu'il renvoi nul dans des cas exceptionnels ? Après tout il y a pleins pleins pleins de types de données et il n'y a que pour 2 types de données qu'il renvoit nul cela sonne comme des exceptions non ?

Je suis assez curieux de voir le code de l'appelant..

Citation:

---

Envoyé par hegros

mouais il faut dire que je ne considère pas nul comme une valeur comme les autres. C'est une valeur particulière d'ailleurs il écrit en bleu dans l'éditeur pour toujours se le rappeler et il y'a même un opérateur spécial(?) pour spécifier les variables acceptant cette valeur :aie:

---

Certes, c'est une valeur particulière... ce qui ne veut pas dire qu'elle ne peut pas servir de valeur de retour ;)

Citation:

---

Envoyé par hegros

Après si tu regardes dans le framework, les méthodes de conversion renvoient en général une exception et pas nul sauf pour les variantes TryConvertXXX mais bon je m'avance peut être un peu là.

---

Tu penses sans doute à TryParse ? Ca renvoie un bool, et le résultat est passé en paramètre out. Effectivement la plupart des conversions du framework ne renvoient pas null, mais c'est surtout parce que ça n'aurait pas de sens. Dans certains scénarios, selon les règles que tu définis pour une conversion, ça peut avoir un sens...

Sinon l'opérateur as renvoie null si la conversion échoue, mais bon, c'est un cas un peu particulier...

Citation:

---

Envoyé par hegros

Pour revenir au code, tu n'es pas d'accord qu'il renvoi nul dans des cas exceptionnels ? Après tout il y a pleins pleins pleins de types de données et il n'y a que pour 2 types de données qu'il renvoit nul cela sonne comme des exceptions non ?

---

Je ne pense pas que ce soit supposé être un code complet, c'est juste un exemple pour illustrer... donc il vaut mieux éviter d'en tirer des conclusions ;)

Merci tomlev, c'est exactement cette réponse que je voulais.
Je ne connaissais pas l'opérateur is (c'est peut-être choquant? :?)

Pour expliquer pourquoi je voulais cette fonction:
Elle est appelée par un void de la couche la plus basse, celle liée à la base de données donc, et me permet d'enregistrer des paramètres null au lieu de Int.MinValue dans une colonne avec une contrainte de clé étrangère avec une autre table.
Car la valeur int.MinValue n'existe pas dans ma table originale...

Citation:

---

Envoyé par cyrano_de_bergerac

Pour expliquer pourquoi je voulais cette fonction:
Elle est appelée par un void de la couche la plus basse, celle liée à la base de données donc, et me permet d'enregistrer des paramètres null au lieu de Int.MinValue dans une colonne avec une contrainte de clé étrangère avec une autre table.
Car la valeur int.MinValue n'existe pas dans ma table originale...

---

Si c'est pour enregistrer une valeur nulle dans la BDD, je te conseille de renvoyer DBNull.Value plutôt que null, ça rendra la chose plus explicite...

Citation:

---

Envoyé par tomlev

Si c'est pour enregistrer une valeur nulle dans la BDD, je te conseille de renvoyer DBNull.Value plutôt que null, ça rendra la chose plus explicite...

---

Ok j'en prends bonne note.
Merci infiniement! :D

Citation:

---

Envoyé par tomlev

Je ne pense pas que ce soit supposé être un code complet, c'est juste un exemple pour illustrer... donc il vaut mieux éviter d'en tirer des conclusions ;)

---

Ce ne sont pas des conclusions mais des interprétations à partir de code que l'on veut bien nous montrer. Les conclusions, au niveau de la hiérarchie de l'écoute, est équivalent au jugement donc bien après l'interprétation ;)