Quand exactement les types nullables lèvent-ils des exceptions ?

Question

Considérons le code suivant :

int? x = null;
Console.Write ("Hashcode: ");
Console.WriteLine(x.GetHashCode());
Console.Write("Type: ");
Console.WriteLine(x.GetType());

Lorsqu'il est exécuté, il écrit que Hashcode est 0 mais échoue avec NullReferenceException pour tenter de déterminer le type de x . Je sais que les méthodes appelées sur les types nullables sont en fait appelées sur les valeurs sous-jacentes, et je m'attendais donc à ce que le programme échoue lors de l'exécution du programme. x.GetHashCode() .

Alors, quelle est la différence fondamentale entre ces deux méthodes et pourquoi la première n'échoue-t-elle pas ?

Answer 1

Cela s'explique par le fait que int? x = null; crée essentiellement une instance du type de valeur System.Nullable<int> avec un "intérieur" null (vous pouvez le vérifier via .HasVaue Propriété). Lorsque GetHashCode est invoquée, la dérogation Nullable<int>.GetHashCode est la méthode candidate (puisque la méthode est virtuelle), nous avons maintenant une instance de Nullable<int> et exécute sa méthode d'instance, parfaite.

Lorsque vous invoquez GetType la méthode est non virtuelle, donc l'instance de Nullable<int> est mis en boîte pour System.Object d'abord, selon le document et la valeur encadrée est null d'où le NullReferenceException .

Answer 2

Pour clarifier la réponse correcte de Danny Chen :

• Nullable<T> est un type de valeur. Le type de valeur se compose d'un bool, qui indique la nullité (false signifie null) et d'un T, la valeur.
• Contrairement à tous les autres types de valeurs, les types nullables ne sont pas encadrés par une boîte. Nullable<T> . Il s'agit soit d'une boîte T ou une référence nulle.
• Une méthode mise en œuvre par un type de valeur S est implémenté comme s'il avait un ref S argument ; c'est ainsi que this est adoptée.
• Une méthode mise en œuvre par un type de référence C est mis en œuvre comme s'il existait un C argument ; c'est ainsi que this est adoptée.
• Le cas intéressant est alors une méthode virtuelle définie dans une classe de base de référence et surchargée par une structure qui hérite de la classe de base.

Vous avez maintenant suffisamment d'informations pour déduire ce qui se passe. GetHashCode est virtuel et remplacée par Nullable<T> donc quand vous l'appelez, vous l'appelez comme s'il y avait une invisible ref Nullable<T> argument pour this . Il n'y a pas de boxe.

GetType n'est pas virtuelle et ne peut donc pas être surchargée, elle est définie sur object . Il s'attend donc à un object pour this Lorsqu'il est appelé sur un Nullable<T> le receveur doit être boxé, et donc peut boxer vers le nul, et donc peut lancer.

Si vous avez appelé ((object)x).GetHashCode() alors vous verriez une exception.

Answer 3

La mise en œuvre de Nullable<T>.GetHashCode() est le suivant :

public override int GetHashCode()
{
    if (!this.HasValue)
    {
        return 0;
    }
    return this.value.GetHashCode();
}

Ainsi, lorsque la valeur est nulle, vous obtiendrez toujours 0 .

x.GetType() est identique à null.GetType() qui lancera Object reference not set to an instance of an object

Answer 4

Il semble que GetHashCode ait une vérification de nullité. (J'ai utilisé JetBrains pour voir la définition)

public override int GetHashCode()
{
  if (!this.hasValue)
    return 0;
  return this.value.GetHashCode();
}