Voici un morceau de code:
public abstract class ComponentException<T> : ComponentException
where T : ComponentException, new()
{
public static void FailIfTrue(bool expression, string message)
{
if (expression)
{
T t = new T();
t.SetErrorMessage(message);
throw t;
}
}
//...
}
6 Réponses :
Q1: Parce que Resharper ne fait pas de chemin analyse. Il voit juste une référence Q2: Vous ne pouvez pas faire l'un ou l'autre de ce que vous avez fourni déjà. null référence et indicateurs qui.
Ceci est causé par le moteur Resharper. Ces "NullReferenceException possibles" se produisent parce que quelqu'un (probablement à Resharper) a déclaré / configuré quelque part une annotation sur la méthode.
Voici comment ça fonctionne: Restomer Analyse NullReferenceException et ses contrats
Malheureusement, parfois, ces annotations utiles ne sont pas fausses.
Lorsque vous détectez une erreur, vous devez le signaler à JetBrains et ils mettront à jour les annotations lors de la prochaine version. Ils sont habitués à cela.
Pendant ce temps, vous pouvez essayer de le réparer par vous-même. Lisez l'article pour plus :)
Resharper examine uniquement la méthode actuelle de son analyse et n'analyse pas de manière récursive d'autres méthodes que vous appelez.
Vous pouvez toutefois diriger un peu de rétablissement et lui donner des méta-informations sur certaines méthodes. Il sait par exemple "assert.isnotnull (a)", et prendra en compte ces informations pour l'analyse. Il est possible de créer un fichier d'annotations externe pour Resharper et de lui donner des informations supplémentaires sur une certaine bibliothèque pour améliorer son analyse. Peut-être que cela pourrait offrir un moyen de résoudre votre problème.
Plus d'informations peut être trouvée ici .
Un exemple montrant comment il est utilisé pour la bibliothèque Microsoft.Contracts peut être trouvé Ici .
Vous savez (ou attendez-vous) que ce code lancera une exception s'il existe une référence null: Cependant, étant donné qu'il n'y a pas de contrat spécifiant cela, Resharper doit supposer que Ceci est juste un appel de méthode normal qui peut revenir sans jeter une exception dans aucun cas. p> Faites de cette méthode Implémenter le contrat Restomer, ou comme une solution de contournement simple (qui n'affecte que le mode de débogage, donc aucune pénalité de performance pour Mode de sortie), juste après le échec de l'appels code> appelez: p> Debug.Assert(user != null);
Je souhaitais que c'était vrai ... Resharper 5.1 ne parvient pas à identifier correctement débog.assert (utilisateur! = Null); et soulève l'avertissement. Y a-t-il une configuration que je dois faire?
Euh, r # 5.1 est assez obsolète. Je n'ai donc rien à tester votre problème. Quelques astuces Toutefois: Assurez-vous que votre code désigne correctement la classe System.Diagnostics.debug, car le contrat de code a été défini pour cela, et non pour des méthodes arbitraires avec ce nom / la signature. En outre, assurez-vous que la configuration de construction est définie sur le débogage (sinon, le code est hors de portée et que l'avertissement apparaît donc!).
Une nouvelle réponse dans Old Post ...
Voici un petit échantillon de mon code concernant comment utiliser Codecontract via ContractoNotation avec Resharper: P>
[ContractAnnotation("value:null=>true")]
public static bool IsNullOrEmpty(this string value)
{
return string.IsNullOrEmpty(value);
}
Si vous savez qu'une méthode jette toujours une exception, vous pouvez faire [contraction ("=> HALT")]
Vérifiez si vous avez un utilisateur == null si vous vérifiez au-dessus du code donné. S'il y a, alors Resharper pense que la variable "peut être null", vous vous recommande d'utiliser un chèque / affirmation avant de le référencer. Dans certains cas, c'est la seule façon de resharper peut deviner si une variable peut ou ne peut pas être nulle.