7
votes

Comment éviter plusieurs chèques nuls

DUPLICATES possibles:

Vérification de NULL profonde, y a-t-il une meilleure façon?
C # moyen élégant de vérifier si la propriété d'une propriété est null

Je dois consulter un modèle d'objet profond comme celui-ci: xxx

est là pour évaluer cela et renvoyer null si l'une de la chaîne est NULL (organisationnelle , parent, tête, etc.), sans avoir à faire un xxx


1 commentaires

Essayez d'éviter ce genre de recherche; S'il vous plaît voir ma réponse ci-dessous pour plus de détails.


5 Réponses :


8
votes

Vous recherchez l'opérateur de déséroférence NULL-SAFE ?. (également appelé navigation sûre) que certaines langues (par exemple, groovy) ont, mais malheureusement c # n'a pas cet opérateur.

Espérons que cela sera mis en œuvre un jour ...

Voir aussi Cet article par Eric Lippert. La syntaxe qu'il propose qu'il y a .? .


2 commentaires

Il est plus fréquemment appelé Opérateur de propagation NULL ou NULL Opérateur conditionnel .


Il est maintenant disponible sur c # 6: MSDN.MicRosoft.com/en-us/ Bibliothèque / DN986595.ASPX



7
votes

Avez-vous entendu parler du Loi de Demeter ?

Enchaîs à de telles séquences d'appels aussi longues n'est pas une bonne idée. Cela crée des dépendances affreuses entre les classes dont vous n'avez pas besoin.

Dans votre exemple, la classe contenant p devient dépendante de cinq d'autres classes. Je vous suggère de simplifier votre code et de faire une vérification de chaque classe pour NULLS à un seul niveau, dans leur propre contexte de connaissances.


2 commentaires

D'accord mais pris sur une grande base de code, je ne peux pas le refaire tout dans une journée :)


@OOO: Je comprends. Dans ce cas, je pense que vous devez utiliser la chaîne laid de chèques nuls. J'essaierais d'encapsuler cela dans une méthode privée afin que les dépendances soient isolées et facilement reconnaissables.




7
votes

Consultez Cet article . Il présente une excellente solution qui vous permet d'écrire des choses comme ça: xxx


0 commentaires

-2
votes

Vous pouvez utiliser la manipulation d'exception de base aussi pour attraper cela. Je ne suis pas fou de cette solution, mais c'est une option. Si ces nuls imbriquées sont des opérations normales, des exceptions ne sont probablement pas la bonne réponse:

public class A
{
}
public class B
{
   public A a;
}
public class C
{
    public B b;
}
class Program
{
    static A GetA(C c)
    {
        A myA;
        try
        {
            myA = c.b.a;
        }
        catch
        {
            myA = null;
        }
        return myA;
    }        

    static void Main(string[] args)
    {
        C theC = new C();
        theC.b = new B();
        theC.b.a = new A();
        A goodA = GetA(theC);
        if (goodA != null)
        {
            Console.WriteLine("Expected nominal path.");
        }
        else
        {
            Console.WriteLine("Unexpected nominal path.");
        }
        theC.b.a = null;
        A badA = GetA(theC);
        if (badA == null)
        {
            Console.WriteLine("Expected off-nominal path.");
        }
        else
        {
            Console.WriteLine("Unexpected off-nominal path.");
        }

    }

}


2 commentaires

Invoquant le système de traitement des exceptions semble excessif pour des opérations normales; Cependant, comme vous l'avez dit, c'est une solution, pensant en dehors de la boîte.


@John K: Je suis d'accord - la seule façon dont j'avais jamais envisagé de considérer que ceci est si des NuLs imbriqués représentaient un état "cassé". De plus, il y a le problème de ne pas savoir quelle DÉRÉFERFEFECTURE a cassé le système et la performance frappée. Mais c'est un outil dans la boîte ...