Comment les vérifications de paramètres Null fonctionneront-elles dans C# 11 ? – Informatique CloudSavvy

Un premier aperçu de certaines fonctionnalités à inclure dans la version C# 11 de cette année est désormais disponible dans le cadre de la mise à jour 1 de Visual Studio 2022. L’ajout le plus controversé est la prise en charge intégrée de la vérification des paramètres nuls. Cela utilise la génération de code pour éliminer les comparaisons manuelles avec null.

Dans cet article, nous explorerons l’état actuel de la fonctionnalité, les critiques formulées à son encontre et comment elle pourrait changer avant la version finale. La syntaxe et les comportements décrits ici s’appliquent à l’aperçu C# 11 actuel (mars 2022) et pourraient changer considérablement avant le lancement.

Qu’est-ce que la vérification des paramètres nuls ?

Précisons d’abord de quoi nous parlons. Les paramètres C# sans types de référence nullables acceptent null comme une valeur indépendamment de leur type réel :

private string hello(string name) {
    return "Hello " + name;
}
 
// This works
hello(null);

Ce comportement est souvent indésirable. Dans l’exemple ci-dessus, en passant null produirait une sortie absurde. Pour surmonter ce problème, il est courant que les développeurs ajoutent leurs propres null-vérifie en tête des méthodes :

private string hello(string name) {
 
    if (name is null) {
        throw new ArgumentNullException(nameof(name));
    }
 
    return "Hello " + name;
 
}
 
// ArgumentNullException
hello(null);

Cela peut créer beaucoup de code passe-partout lorsqu’une méthode a plusieurs paramètres non nullables.

Paramètre Null-Checking Syntaxe en C # 11

C# 11 vous permet de condenser l’exemple ci-dessus au code suivant :

private string hello(string name!!) {
    return "Hello " + name;
}
 
// ArgumentNullException
hello(null);

Le spécial !! la syntaxe après le nom du paramètre a le même effet qu’un manuel if (... is null) / throw new ArgumentNullException(...) bloquer. Une ArgumentNullException instance sera lancée si vous passez null à un paramètre qui utilise la syntaxe.

Lorsque plusieurs paramètres sont marqués comme n’acceptant pas la valeur NULL, les vérifications sont exécutées dans l’ordre des paramètres tels qu’ils sont écrits. L’exception levée fera référence au premier paramètre non nullable à recevoir null dans l’invocation.

La syntaxe peut être utilisée avec la plupart des types de paramètres, y compris ceux de async méthodes, itérateurs et lambdas. Cela ne fonctionne pas avec les paramètres de méthode abstraite, extern et les paramètres délégués, et les méthodes d’interface qui ne sont pas une méthode d’interface par défaut (DIM).

Comment ça marche?

La nouvelle syntaxe est basée sur la génération de code compilateur. Le compilateur crée le familier if (... is null) / throw new ArgumentNullException(...) code pendant qu’il traite vos fichiers source.

La fonctionnalité n’ajoute rien aux capacités du langage C#. Il s’agit simplement d’écrire pour vous du code utilisateur commun, offrant une syntaxe concise qui réduit les sections source répétitives.

Le code généré est positionné en haut de chaque méthode affectée. Si la méthode est un constructeur, le code sera exécuté avant les initialisations du champ de classe et tout appel au this et base constructeurs. Il s’agit de la seule différence pratique par rapport aux expressions de vérification null créées manuellement.

Pourquoi est-ce controversé ?

Les détracteurs de la proposition s’inquiètent de la syntaxe (!! communique mal sa signification et son effet), sa présence sur le nom du paramètre au lieu du type, et si la génération de code passe-partout relève des attributions du projet de langage C#. Il existe également des débats sur les interactions de la vérification nulle avec les types de référence nullables.

Découvrons certains de ces arguments et leurs implications.

!! Existe sur le nom du paramètre, pas sur le type

En écrivant string param!! ne semble pas naturel car vous imprégnez apparemment le nom du paramètre d’un comportement supplémentaire, plutôt que le type. Pourtant, cela est tout à fait cohérent avec ce qui se passe réellement.

La vérification de type est une activité au niveau du compilateur ; la vérification nulle du paramètre génère Durée code qui vérifie le évaluer du paramètre. Il est donc logique que la syntaxe cible le paramètre au lieu de son taper.

Les noms de paramètre ne doivent pas faire apparaître les détails d’implémentation

Une autre plainte est que param!! communique des informations sur l’implémentation de la méthode via sa déclaration. La syntaxe n’affecte pas la signature de la méthode, révélant plutôt des aspects de son fonctionnement interne. Ceci est insatisfaisant pour de nombreux développeurs.

Une façon flottante de résoudre le problème consisterait à fournir un comportement de vérification des paramètres null en tant qu’attribut. Ce n’est pas à cela que servent les attributs – ce sont des métadonnées simples alors que les vérifications nulles génèrent du code d’exécution. Il existe également un précédent pour le comportement de !! dans d’autres composants de déclaration de méthode : prendre asyncqui révèle que sa cible est asynchrone et vous connecte un modèle d’exécution approprié.

Compatibilité avec les types de référence nuls

Les contrôles nuls de paramètre et les types de référence nuls (NRT) sont compatibles les uns avec les autres. Cependant, vous verrez de nouveaux avertissements du compilateur si vous combinez !! avec un type nullable :

private string hello(string? name!!) {
    // ...
}

Dans cet exemple le string? le type autorise explicitement null tandis que name!! le rejette à l’exécution. Le compilateur détecte cette condition contradictoire et émet un avertissement :

CS8995 Nullable type 'string?' is null-checked and will throw if null.

Que les deux mécanismes soient conceptuellement compatible est un autre problème. Les types de référence Nullable appliquent une valeur ne peut pas être null au moment de la compilation. Les vérifications nulles des paramètres lèvent une exception lorsqu’une valeur est nul à l’exécution. Dans un paysage idéal, seule la première serait nécessaire – toutes les méthodes utiliseraient les TRN pour indiquer si elles peuvent accepter null et l’application serait entièrement gérée par le compilateur.

Malheureusement, le paysage C # n’est pas idéal. Les types de référence Nullable sont une fonctionnalité opt-in qui n’a pas été universellement adoptée. Il n’est pas réaliste de s’attendre à ce que tout le code existant accumulé au cours des 20 années du langage C# prenne en charge les NRT. Les contrôles nuls des paramètres sont un moyen pragmatique de relier le nouveau code qui utilise principalement des NRT avec des bibliothèques plus anciennes qui peuvent renvoyer null à l’exécution. Ils ont du sens où vos méthodes pourraient être remises null – donc un NRT ne peut pas être utilisé – par un code qui n’a pas adopté l’approche moderne.

C’est une erreur d’approcher param!! comme moyen de signaler que le paramètre ne doit pas être passé null – c’est l’exigence que string? accueille volontiers. La présence de !! n’est connu que du compilateur. C’est là pour élever un ArgumentNullException en votre nom.

La génération de code pourrait être une mauvaise idée

Il existe certaines vues selon lesquelles la génération automatique de code pour exécuter cette fonction peut poser plus de problèmes que cela n’en vaut la peine. Bien que cela puisse supprimer beaucoup de passe-partout, cela peut également provoquer des comportements inattendus et rendre plus difficile le raisonnement sur le programme.

Les développeurs doivent comprendre que ArgumentNullException les instances peuvent être lancées n’importe où !! est utilisé. L’exception est inflexible et ne peut pas être modifiée, même dans des situations telles que les membres d’instance où un NullReferenceException peut être plus approprié. Cela a conduit certains commentateurs à suggérer que les vérifications null de paramètres dans leur forme actuelle ne devraient pas faire partie de C#.

Il n’y a pas de réponse directe à ce problème. De toute évidence, l’équipe de développement C # a décidé que la génération de code aurait un avantage net positif sur la communauté en faisant gagner du temps et en réduisant la répétitivité. Cependant, il convient de reconnaître que les vérifications nulles entraînent l’ajout d’un code unique à votre projet, ce qui crée la possibilité de problèmes si cette taille s’avère ultérieurement incorrecte.

Sommaire

Deux personnages ont créé une discussion qui n’a pas encore commencé : dans l’état actuel des choses, param!! arrive en C# comme moyen de générer throw ArgumentNullException(...) pour toi. Malgré son potentiel d’allégement du code standard – plus de 20 000 vérifications nulles explicites ont été supprimées de .NET Runtime à l’aide de la syntaxe – il reste un certain nombre de doutes et de préoccupations persistants.

Nous avons disséqué les plus importants d’entre eux ci-dessus et avons constaté que la plupart des plaintes sont infondées et basées sur des malentendus. La plus grande critique concerne sans doute la syntaxe elle-même, avec !! considéré comme opaque, difficile à découvrir et inaccessible aux nouveaux arrivants. Il existe diverses propositions pour le remplacer par quelque chose de plus évident; string param notnull fait l’objet d’une attention considérable, de sorte que la forme finale peut sembler différente lorsque C# 11 arrive.

Vous pouvez donner votre avis sur la proposition en contribuant à son fil de discussion sur GitHub. Si vous souhaitez essayer l’aperçu actuel par vous-même, vous aurez besoin de Visual Studio 17.1 (2022 Update 1) et de .NET SDK 6.0.200. Vous devrez alors changer LangVersion pour preview au sein de votre .csproj fichier pour activer la prise en charge de C# 11.