Je voudrais empêcher la poursuite du traitement d'un objet s'il est nul.
Dans le code suivant, je vérifie si l'objet est nul par soit :
if(!data.Equals(null))
et
if(data != null)
Cependant, je reçois un NullReferenceException
sur dataList.Add(data)
. Si l'objet était nul, il n'aurait même pas dû entrer dans l'énoncé if !
Je demande donc si c'est une bonne façon de vérifier si un objet est nul :
public List<Object> dataList;
public bool AddData(ref Object data)
bool success = false;
try
{
// I've also used if(data != null) which hasn't worked either
if (!data.Equals(null))
{
//NullReferenceException occurs here ...
dataList.Add(data);
success = doOtherStuff(data);
}
}
catch (Exception e)
{
throw new Exception(e.ToString());
}
return success;
}
Si c'est la bonne façon de vérifier si l'objet est nul, qu'est-ce que je fais mal (comment puis-je empêcher la poursuite du traitement de l'objet pour éviter l'exception NullReferenceException) ?
14 votes
Vous devez également utiliser
throw e;
contrethrow new Exception(e.ToString());
0 votes
Est-ce que le
data
initialisé avant de vérifier s'il est nul ? Ou cela vient-il d'une base de données ?20 votes
En C#, vous devez toujours utiliser
!= null
dans vos contrôles nuls..Equals
lèvera toujours une exception si l'objet est nul.49 votes
@Nix :
throw e;
n'est pas beaucoup mieux.throw;
d'un autre côté...0 votes
@Nix : Quelle est la raison de faire
throw e
au lieu de ce que j'ai ? (Merci !)4 votes
@développeur :
e.ToString()
produira une chaîne de caractères qui inclut non seulement le message d'erreur, mais aussi ceux de toutes lesInnerExceptions
et la trace de la pile. Il s'agit donc d'un message d'exception très lourd. Si vous souhaitez (à juste titre !) conserver ces informations, et les garder à leur place, utilisez simplementthrow;
.0 votes
@Nix ...et c'est exactement pourquoi vous devriez faire comme @Jon le suggère
2 votes
@developer Just go with
throw;
19 votes
Le try/catch ne fait rien pour le moment. Tout le monde dit qu'il suffit d'utiliser "throw", mais si vous ne faites rien d'autre avec l'exception que de la relancer, pourquoi avoir un bloc try/catch ? Habituellement, vous attrapez les exceptions pour les traiter de manière élégante, nettoyer les ressources (mieux avec la clause "finally") ou faire une sorte de journalisation avant de relancer l'exception. Rien de tout cela ne se produit dans ce code, donc il n'y a aucun besoin de try/catch.
1 votes
Une petite mise à jour : C# 7 supporte
is null
Ainsi, pour votre premier chèque, vous pourriez écrireif (data is null) return false;
pour réduire l'imbrication et utiliser la syntaxe (imo) plus propre.