J'ai pensé qu'il serait utile de pouvoir faire une telle chose, par exemple, de vérifier les paramètres des références nulles et de lancer éventuellement une exception.
Cela permettrait d'économiser une frappe et empêcherait également d'oublier d'ajouter un chèque si un nouveau paramètre est ajouté. P>
8 Réponses :
Il est possible de parcourir les paramètres déclarés pour une méthode (via une réflexion), mais je ne vois aucun moyen de récupérer la valeur de ces paramètres d'une méthode spécifique ... P>
Peut-être que vous pourriez utiliser postSharp et créer un aspect dans l'endroit où vous effectuez ce chèque. Ensuite, à l'heure de la compilation, postSharp peut "tisser" l'aspect (injecter du code supplémentaire) à chaque méthode que vous avez écrite ... p>
Vous pouvez consulter Le bloc d'application de validation qui peut être traité comme un exemple de validation automatisée et Le bloc d'application Unity (dans Son caractéristique d'interception particulière) en ce qui concerne l'interception d'appels et l'inspection des paramètres. P>
Eh bien, non si vous ne comptez pas:
public void Foo(string! x, object! y, Stream! z, int a) { // Compiler would generate Code Contracts calls here }
Dans votre cas, qu'en est-il de Checknotnull ((objet []) null)? :-)
Pensez que l'auteur signifiait quelque chose comme les arguments de JavaScript. Par exemple. Répertoriez tous les arguments dans "FOO (String x, objet y, z, int a)" méthode et testez-les pour NULL sans spécifier chacun d'entre eux, mais appelez à une méthode générique comme "validateargs (foo.arguments);" .
@ Dzmititry: Eh bien, oui - vous ce n'est pas encore prêt à la production :)
Un problème avec cette approche, c'est que vous devez écrire 'CheckNotnull' dans chaque méthode, qui est assez fastidieuse ...
@KamArey: Vous ne pouvez pas faire cela, d'où la "non si vous ne comptez pas". Néanmoins, c'est une déclaration dans chaque cas.
@Frederik: Si vous voulez que ce soit déclaratif, vous devez utiliser quelque chose comme la route post-poste, comme nous l'avons mentionné tous les deux.
Je suis enfant =) Je sais que vous savez tout ce genre de choses. Au fait, j'ai hâte de lire 2e édition de C # en profondeur. J'ai aimé la première édition. O, une chose de plus - qu'en est-il du "livre de rêve"? Y a-t-il un mouvement là-bas?
Leur QI suffit seulement pour le vote en bas, pas un commentaire
"Certes, j'aurais probablement envie de la convertir en Postsharp en appels de contrats de code" Pourquoi? Dans ce cas simple ne serait-il pas un si -en-the-jet va bien?
@ROBSULLIVAN: Parce que si c'est un appel de code, le checker statique serait en mesure de m'empêcher si cela pensait que je pourrais passer dans un argument null. Vérification statique Rocks :)
@Jon Skeet: Oui, vérification statique des roches en effet. Mais dans les contrats de code actuels, il ne fonctionne que avec VSTS, que je ne peux pas vous permettre: (peut-être qu'il sera disponible pour tout le monde dans VS2010 avec l'inclusion des contrats de code dans .NET 4.0?
@ DzMititry: Re le "livre de rêve" - Je ne fais rien vraiment activement avec l'idée. Mais j'ai des parties intéressées. Il peut encore arriver, sous une forme ou autre :)
Je veillerai à voter, sans que les contrats de code d'analyse statique ne soient très petits pour moi. Merci pour la grande réponse.
Vous pouvez définir le paramètre de méthode avec un mot-clé code> paramètres code>. Cela permettra de passer un nombre de paramètres de longueur variable à votre méthode. Vous pouvez ensuite itérer sur eux et vérifier les références nulles ou ce que vous voulez avec elle. À mon avis cependant, ce n'est pas un bon moyen de faire les choses. Vous devrez contrôler manuellement le type de vos paramètres, leur position dans la matrice d'entrée et vous ne pourrez pas utiliser IntelliSense pour eux dans Visual Studio. P> P>
Vous pouvez aussi probablement automatiser la vérification des paramètres avec un Bibliothèque AOP tel que postSharp . p>
J'ai eu la même question il y a quelque temps, mais je voulais le faire à des fins de journalisation. Je n'ai jamais trouvé de bonne solution, mais j'ai trouvé ce lien concernant l'utilisation d'une approche basée sur l'AOP pour les entrées de la méthode de journalisation et la sortie. L'essentiel est nécessaire d'utiliser un cadre capable de lire votre classe et d'injecter le code à l'exécution pour faire ce que vous essayez de faire. Ne semble pas facile. P>
Comment puis-je intercepter une méthode appeler C #? < / a> p>
Après avoir fourni un exemple trivial d'une méthode à l'aide du mot-clé code> parames code>, Rayell dit:
À mon avis cependant, ce n'est pas un bon façon de faire des choses. Tu vas devoir contrôler manuellement le type de votre paramètres, leur position dans le Array d'entrée et vous ne pourrez pas Utilisez IntelliSense pour eux à Visual Studio. P> blockQuote>
Je suis certainement d'accord pour dire que déclarer une méthode qui prend deux
Strings code>, un
int code>, un objet
code> qui peut être null et un autre objet
myClass code> à l'aide des paramètres code> est une mauvaise idée. Cependant, il sont em> (à mon avis) des applications parfaitement valides et appropriées du mot clé code> parames code>, à savoir lorsque les paramètres sont tous du même type. Par exemple: p>
xxx pré> p>
if(mandatoryFields.ToArray().Count > 0){}