Pourquoi est-il valide de concaténer des chaînes nulles mais pas d'appeler «null.ToString ()»?

C'est un code C # valide

var bob = "abc" + null + null + null + "123";  // abc123

Ce n'est pas un code C # valide

var wtf = null.ToString(); // compiler error

Pourquoi la première déclaration est-elle valide?

La raison pour laquelle le premier fonctionne:

Depuis MSDN :

Dans les opérations de concaténation de chaînes, le compilateur C # traite une chaîne nulle de la même manière qu'une chaîne vide, mais il ne convertit pas la valeur de la chaîne nulle d'origine.

Plus d'informations sur l' opérateur binaire + :

L'opérateur binaire + effectue la concaténation de chaînes lorsqu'un ou les deux opérandes sont de type chaîne.

Si un opérande de concaténation de chaînes est nul, une chaîne vide est remplacée. Sinon, tout argument non-chaîne est converti en sa représentation sous forme de chaîne en appelant la ToStringméthode virtuelle héritée de type object.

Si ToStringretourne null, une chaîne vide est remplacée.

La raison de l'erreur en seconde est:

null (référence C #) - Le mot clé null est un littéral qui représente une référence null, une référence qui ne fait référence à aucun objet. null est la valeur par défaut des variables de type référence.

Parce que l' +opérateur en C # se traduit en interne par String.Concat, qui est une méthode statique. Et cette méthode se traite nullcomme une chaîne vide. Si vous regardez la source de String.ConcatReflector, vous la verrez:

// while looping through the parameters
strArray[i] = (str == null) ? Empty : str;
// then concatenate that string array

(MSDN le mentionne également: http://msdn.microsoft.com/en-us/library/k9c94ey1.aspx )

D'autre part, ToString()est une méthode d'instance, que vous ne pouvez pas appeler null(pour quel type utiliser null?).

Le premier échantillon sera traduit en:

var bob = String.Concat("abc123", null, null, null, "abs123");

La Concatméthode vérifie l'entrée et traduit null comme une chaîne vide

Le deuxième échantillon sera traduit en:

var wtf = ((object)null).ToString();

Une nullexception de référence sera donc générée ici

La première partie de votre code est simplement traitée comme ça dans String.Concat,

qui est ce que le compilateur C # appelle lorsque vous ajoutez des chaînes. " abc" + nullest traduit en String.Concat("abc", null),

et en interne, cette méthode remplace nullpar String.Empty. C'est pourquoi votre première partie de code ne lève aucune exception. c'est juste comme

var bob = "abc" + string.Empty + string.Empty + string.Empty + "123";  //abc123

Et dans la 2ème partie de votre code lève une exception car «null» n'est pas un objet, le mot-clé null est un littéral qui représente une référence nulle , qui ne fait référence à aucun objet. null est la valeur par défaut des variables de type référence.

Et ' ToString()' est une méthode qui peut être appelée par une instance d'un objet mais pas par n'importe quel littéral.

Dans le framework COM qui a précédé .net, il était nécessaire que toute routine recevant une chaîne la libère lorsqu'elle en avait fini avec elle. Étant donné qu'il était très courant que des chaînes vides soient passées dans et hors des routines et que la tentative de «libération» d'un pointeur nul était définie comme une opération légitime de ne rien faire, Microsoft a décidé de faire en sorte qu'un pointeur de chaîne nulle représente une chaîne vide.

Pour permettre une certaine compatibilité avec COM, de nombreuses routines dans .net interpréteront un objet nul comme une représentation légale comme une chaîne vide. Avec quelques légères modifications .net et ses langages (permettant notamment aux membres d'instance d'indiquer «ne pas invoquer comme virtuel»), Microsoft aurait pu faire en sorte que les nullobjets du type déclaré String se comportent encore plus comme des chaînes vides. Si Microsoft avait fait cela, il aurait également dû faire Nullable<T>fonctionner un peu différemment (afin de permettre - Nullable<String>quelque chose qu'ils auraient dû faire de toute façon à mon humble avis) et / ou définir un NullableStringtype qui serait principalement interchangeable avec String, mais qui ne considérerait pas un nullcomme une chaîne vide valide.

En l'état, il existe certains contextes dans lesquels a nullsera considéré comme une chaîne vide légitime et d'autres dans lesquels il ne le sera pas. Ce n'est pas une situation très utile, mais une situation dont les programmeurs devraient être conscients. En général, les expressions du formulaire stringValue.someMemberéchoueront si stringValuec'est le cas null, mais la plupart des méthodes et opérateurs du framework qui acceptent des chaînes comme paramètres seront considérés nullcomme une chaîne vide.

'+'est un opérateur d'infixe. Comme tout opérateur, il appelle vraiment une méthode. Vous pouvez imaginer une version non infixée"wow".Plus(null) == "wow"

Le réalisateur a décidé de quelque chose comme ça ...

class String
{
  ...
  String Plus(ending)
  {
     if(ending == null) return this;
     ...
  }
} 

Alors ... votre exemple devient

var bob = "abc".Plus(null).Plus(null).Plus(null).Plus("123");  // abc123

qui est le même que

var bob = "abc".Plus("123");  // abc123

À aucun moment, null ne devient une chaîne. Ce null.ToString()n'est donc pas différent de cela null.VoteMyAnswer(). ;)

Je suppose que c'est un littéral qui ne fait référence à aucun objet. ToString()a besoin d'un object.

Quelqu'un a dit dans ce fil de discussion que vous ne pouvez pas créer de chaîne avec rien. (qui est une belle phrase comme je pense). Mais oui - vous pouvez :-), comme le montre l'exemple suivant:

var x = null + (string)null;     
var wtf = x.ToString();

fonctionne bien et ne lève pas du tout d'exception. La seule différence est que vous devez convertir l'une des valeurs nulles en une chaîne - si vous supprimez la conversion (chaîne) , l'exemple se compile toujours, mais lève une exception d'exécution: "L'opérateur '+' est ambigu sur les opérandes de tapez '<null>' et '<null>' ".

NB Dans l'exemple de code ci-dessus, la valeur de x n'est pas nulle comme on pourrait s'y attendre, c'est en fait une chaîne vide après avoir transtypé l'un des opérandes en une chaîne.

Un autre fait intéressant est qu'en C # / .NET, la manière dont nullest traitée n'est pas toujours la même si vous considérez différents types de données. Par exemple:

int? x = 1;  //  string x = "1";
x = x + null + null;
Console.WriteLine((x==null) ? "<null>" : x.ToString());

Regardez la 1ère ligne de l'extrait de code: si xest une variable entière Nullable (c'est-à-dire int?) contenant une valeur 1, alors vous récupérez le résultat <null>. S'il s'agit d'une chaîne (comme indiqué dans le commentaire) avec une valeur "1", vous récupérez "1"plutôt que <null>.

NB Aussi intéressant: si vous utilisez var x = 1;pour la première ligne, vous obtenez une erreur d'exécution. Pourquoi? Parce que l'affectation transformera la variable xen type de données int, qui n'est pas nullable. Le compilateur ne suppose pas int?ici, et échoue donc dans la 2ème ligne où nullest ajouté.

L'ajout nullà une chaîne est simplement ignoré. null(dans votre deuxième exemple) n'est une instance d'aucun objet, donc il n'a même pas de ToString()méthode. C'est juste un littéral.

Parce qu'il n'y a aucune différence entre string.Emptyet nullquand vous concattez des chaînes. Vous pouvez également transmettre null string.Format. Mais vous essayez d'appeler une méthode on null, ce qui entraînerait toujours un NullReferenceExceptionet donc générerait une erreur de compilation.
Si, pour une raison quelconque, vous voulez vraiment le faire, vous pouvez écrire une méthode d'extension, qui vérifie nullet retourne string.Empty. Mais une extension comme celle-ci ne devrait être utilisée que lorsqu'elle est absolument nécessaire (à mon avis).

En général: il peut ou non valider l'acceptation de null comme paramètre en fonction de la spécification, mais il est toujours invalide d'appeler une méthode sur null.

C'est et un autre sujet pourquoi les opérandes de l'opérateur + peuvent être nuls dans le cas de chaînes. C'est un peu quelque chose de VB (désolé les gars) pour faciliter la vie des programmeurs, ou en supposant que le programmeur ne peut pas gérer les valeurs nulles. Je suis complètement en désaccord avec cette spécification. 'inconnu' + ​​'n'importe quoi' doit être toujours 'inconnu' ...