Discussion :

[cyrano_de_bergerac]

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 :

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

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

[Pol63]

plusieurs moyens

if gettype(o) is string


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

[hegros]

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.

[tomlev]

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

Code :

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

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;
}

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...

[hegros]

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.

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...

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)

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

[tomlev]

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

MSDN par exemple :

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

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.

[Pol63]

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