Erkennen, was das Zielobjekt ist, wenn NullReferenceException ausgelöst wird

Ich bin mir sicher, dass wir alle schon einmal die wunderbar vage Ausnahme "Objektreferenz nicht auf Instanz eines Objekts gesetzt" erhalten haben. Das Identifizieren des Objekts, das das Problem darstellt, ist oft eine mühsame Aufgabe, Haltepunkte zu setzen und alle Mitglieder in jeder Anweisung zu untersuchen.

Hat jemand irgendwelche Tricks, um das Objekt, das die Ausnahme verursacht, einfach und effizient zu identifizieren, entweder über programmgesteuerte Mittel oder auf andere Weise?

--bearbeiten

Es scheint, ich war vage wie die Ausnahme =). Der Punkt ist, _nicht die App debuggen zu müssen, um das fehlerhafte Objekt zu finden. Der Compiler/Laufzeit weiß, dass das Objekt zugewiesen/deklariert wurde und dass das Objekt noch nicht instanziiert wurde. Gibt es eine Möglichkeit, diese Details in einer abgefangenen Ausnahme zu extrahieren / zu identifizieren?

@ W. Craig Trader

Ihre Erklärung, dass dies auf ein Designproblem zurückzuführen ist, ist wahrscheinlich die beste Antwort, die ich bekommen konnte. Ich bin ziemlich zwanghaft mit defensivem Codieren und habe es geschafft, die meisten dieser Fehler loszuwerden, nachdem ich meine Gewohnheiten im Laufe der Zeit korrigiert habe. Die verbleibenden optimieren mich einfach ohne Ende und führen mich dazu, diese Frage an die Community zu stellen.

Danke für alle Vorschläge.

Lösung des Problems

An dem Punkt, an dem das NRE geworfen wird, gibt es kein Zielobjekt – das ist der Punkt der Ausnahme. Sie können höchstens darauf hoffen, die Datei- und Zeilennummer abzufangen, in der die Ausnahme aufgetreten ist. Wenn Sie Probleme haben, festzustellen, welche Objektreferenz das Problem verursacht, sollten Sie Ihre Codierungsstandards überdenken, da es so klingt, als würden Sie zu viel in einer Codezeile tun.

Eine bessere Lösung für diese Art von Problem ist Design by Contract, entweder durch eingebaute Sprachkonstrukte oder über eine Bibliothek. DbC würde vorschlagen, alle eingehenden Argumente für eine Methode auf Daten außerhalb des zulässigen Bereichs (dh: Null) vorab zu überprüfen und Ausnahmen auszulösen, da die Methode mit fehlerhaften Daten nicht funktioniert.

[Bearbeiten, um Frage zu bearbeiten:]

Ich denke, die NRE-Beschreibung führt Sie in die Irre. Das Problem, das die CLR hat, besteht darin, dass sie aufgefordert wurde, eine Objektreferenz zu dereferenzieren, wenn die Objektreferenz Null ist. Nehmen Sie dieses Beispielprogramm:

public class NullPointerExample {
 public static void Main()
 {
 Object foo;
 System.Console.WriteLine( foo.ToString() );
 }
}

Wenn Sie dies ausführen, wird in Zeile 5 ein NRE ausgelöst, wenn versucht wurde, die Methode ToString() auf foo auszuwerten. Es gibt keine zu debuggenden Objekte, nur eine nicht initialisierte Objektreferenz (foo). Es gibt eine Klasse und eine Methode, aber kein Objekt.

Betreff: Antwort von Chris Marasti-Georg:

Sie sollten NRE niemals selbst auslösen – das ist eine Systemausnahme mit einer bestimmten Bedeutung: Die CLR (oder JVM) hat versucht, eine Objektreferenz auszuwerten, die nicht initialisiert wurde. Wenn Sie eine Objektreferenz vorab überprüfen, lösen Sie entweder eine Art ungültige Argumentausnahme oder eine anwendungsspezifische Ausnahme aus, aber nicht NRE, da Sie nur den nächsten Programmierer verwirren, der Ihre App warten muss.