Gerade heute, oder eigentlich gestern, ärgerte mich wieder einmal eine einfache null-Prüfung einer Klasse welche die Schnittstelle IComparable<T> implementiert. Die besagte Klasse ist nichts anderes als ein Container für verschiedene Typen und ein paar Vergleichsmethoden sowie überschriebene Operatoren. Sämtliche Vergleiche und Sortierungen funktionieren einwandfrei, solange die Klasse nicht mit null initialisiert und anschließend auf null geprüft wird. Sobald dies geschieht, wird im ersten expliziten Vergleich der Methode
public bool Equals(T other)
eine NullReferenceException geworfen.
Warum gerade in dieser Methode?
Weil der überschriebene Operator != genau diese Methode zum vergleich verwenden muss, um einen expliziten Vergleich aller Eigenschaften der Klasse zu vergleichen.
public static bool operator !=(DownloadFile file1, DownloadFile file2)
{
return !file1.Equals(file2);
}Trotz stundenlanger Suche und lesen unzähliger Artikel, bin ich auf keinen vernünftigen Ansatz gestoßen um das Problem zu lösen. Also habe ich mich für eine brachiale Methode entschieden und gegen den Grundsatz der da heißt:
“Ausnahmen sollen nicht für den regulären Ablauf im Code verwendet werden.”
Vieleicht fällt mir ja noch eine andere Lösung ein, oder jemand stößt mich mit der Nase darauf. Doch bis dahin bleiben die Überprüfungen der einzelnen Eigenschaften in einem try-Block verpackt und die NullReferenceException wird abgefangen.
public bool Equals(DownloadFile other)
{
try
{
if (string.Compare(this.Description, other.Description, StringComparison.Ordinal) != 0)
{
return false;
}
if (!this.FileId.Equals(other.FileId))
{
return false;
}
// hier noch weitere Vergleiche
}
catch (NullReferenceException)
{
// zweite Instanz ist null
return false;
}
return true;
}Es ist mit Sicherheit kein schönes Design; doch bis ich eine bessere Methode gefunden habe, muss ich wohl damit leben.
Wenn ihnen der Artikel gefallen hat oder er für sie hilfreich war, bitte "kicken" sie ihn.
