Laden...

Welchen Vorteil hat die ArgumentNullException zur NullReferenceExcpetion?

Letzter Beitrag vor 13 Jahren 13 Posts 1.466 Views
Welchen Vorteil hat die ArgumentNullException zur NullReferenceExcpetion?

Hallo,

ich hab mal ne Frage zum Exceptionhandling


public void Test(object param)         
{            
      //some checks             
      if (param == null)             
      {                 
                   throw new ArgumentNullException("param");            
      }              

      // do something            
      Console.WriteLine(param.ToString());         
}

Macht das überprüfen des Pramaters auf null überhaupt sinn?

Würde in der Zeile

Console.WriteLine(param.ToString());  

nicht sowiese so eine NullReferenceExcpetion geworfen werden?

Welchen Vorteil hat die ArgumentNullException zur NullReferenceExcpetion?

Danke

Ein Vorteil wäre z.B., dass man direkt sieht, dass ein übergebenes Argument den Wert null hat und nicht innerhalb der für den Benutzer evtl. nicht einsehbaren Klasse ein Fehler ist, der zu einer NullReferenceException führt. Desweiteren kannst du natürlich einen eigenen Text für die Exception angeben und evtl. sogar mitteilen, welcher Parameter null ist usw... Natürlich mach es in diesen Fällen nur Sinn für Debugginginformationen. Vielleicht fallen jemand anderen aber auch noch andere Gründe ein?

Hallo lordbauer,

ArgumentNullException wird ausgelöst, wenn eine Methode aufgerufen wird und mindestens eines der übergebenen Argumente NULL (Nothing in Visual Basic) ist, obwohl es nicht NULL (Nothing in Visual Basic) sein darf.

Beachten Sie, dass Anwendungen eher die ArgumentNullException-Ausnahme als die hier diskutierte NullReferenceException-Ausnahme auslösen.

Ich bin folgender Meinung:

Wenn ein Methodenaufruf einer fremden Klasse eine NullReferenceException wirft, dann kann dies mehrere Ursachen haben. Das Übergebene Objekt ist null, oder es liegt sonst irgend ein Fehler in der Methode vor (wieso NullReferenceE erscheint weisst du hoffentlich). Grundsätzlich kann man dann nur raten warum der Fehler auftritt. Jedoch eine ArgumentNullException weist den Programmierer darauf hin dass ein Parameter null ist, oder eine benötigte Property des zu übergebenden Objekts

Gruß
Michael

Mein Blog
Meine WPF-Druckbibliothek: auf Wordpress, myCSharp

Sagen die Namen ja schon.
Eine NullReferenceException fliegt immer, wenn irgendwo etwas versucht wird und einem ein null in die Quere kommt. Der geneigte User hat somit gar keine Ahnung, was nicht geht.

Die ArgumentNullException hat ja schon das Teilwort "Argument" dabei. Welche zuständig wäre wenn zBsp übergebene Argumente in eine Methode null sind und es eigtl nicht sein sollten. Hier weiß der User wenigstens woran es dann hängt, ob ers ändern kann ist eine andere Frage 😉

Ah ich verstehe!

Und was für eine Exception werft Ihr dann bei folgendem code


public void DoSomething()
{
      Object test = Factory.CreateObject()
      if (test == null)
      {
              throw new ????Exception()
      }
}

ArgumentNulLExcpetion passt hier ja nicht mehr wirklich oder?

Kommt ganz auf den Kontext an. Du willst ja mit der Exception möglichst präzise mitteilen, was schief gelaufen ist. Schau dir mal die verschiedenen Exception-Klassen an, da gibt es schon ein ganze Menge, du kannst dir aber auch eigene Exception-Klassen ableiten. Im konkreten Fall würde ich z.B. eine InvalidOperationExcepetion werfen.

Weeks of programming can save you hours of planning

Das schaut für mich nach einer hundsgemeinen NullReferenceException aus.

Statt aber einfach eine Exception zu werfen könnte man auch eine detailiertere Ausgabe für den User machen und evt (wenn es das Programm hergibt) in einen konsistenten Zustand zurückgehen. Fände ich von der Benutzerfreundlichkeit her angenehmer als eine Exception zu werfen und das Programm dicht zu machen.

Aber das hängt ja wie gesagt stark davon ab was es für ein Programm ist.

ArgumentNulLExcpetion passt hier ja nicht mehr wirklich oder?

Nein - hier sollte ein Debug.Assert(test != null) stehen, da ein CreateObject nie null zurückgeben sollte.

Eine NullReferenceException manuell zu werfen, ist ziemlich sinnfrei - das passiert früher oder später nicht.

Statt aber einfach eine Exception zu werfen könnte man auch eine detailiertere Ausgabe für den User machen

Nein, nicht wenn das wirklich "nie auftreten sollte". Dann sollte wirklich eine Exception geworfen werden.
Diese kann jedoch gefangen werden und dann dem User - wie du gesagt hast - eine Meldung präsentiert werden bzw. ein Fehlerbericht verschickt.

Ein Vorteil wäre z.B., dass man direkt sieht, dass ein übergebenes Argument den Wert null hat und nicht innerhalb der für den Benutzer evtl. nicht einsehbaren Klasse ein Fehler ist, der zu einer NullReferenceException führt. Desweiteren kannst du natürlich einen eigenen Text für die Exception angeben und evtl. sogar mitteilen, welcher Parameter null ist usw... Natürlich mach es in diesen Fällen nur Sinn für Debugginginformationen. Vielleicht fallen jemand anderen aber auch noch andere Gründe ein?

Für mich hat das mit Debugging und evtl. Weitergabe besserer Fehlertexte weniger zu tun. Eine ArgumentNullException und eine NullReferenceException haben genau genommen eine vollständig unterschiedliche Qualität:

Auf eine ArgumentNullException kann ich in einem Grossteil der Fälle noch reagieren. Ich weiss nämlich(bzw. hoffe zu wissen), dass von der eigentlichen Aktion die ich mit dem Methodenaufruf erreichen wollte noch überhaupt nichts geschehen ist. D.h. ich bin noch am Ausgangspunkt des Aufrufs... bestenfalls konsistenter Zustand. Bei einer NullReferenceException hingegen kann ich dazu gar keine Annahmen mehr machen. Es kann sein, dass die Festplatte noch gar nicht angerührt wurde, schon halb formatiert oder zu 3/4 formatiert ist. Ich kann weder reagieren noch dem Benutzer eine entsprechende Meldung geben.

Natürlich muss man dabei immer darauf vertrauen, dass kein Unwissender mal eben eine ArgumentNullException wirft, nachdem bereits andere Anweisugen innerhalb einer Methode ausgeführt wurden...

Grüsse,

N1ls

zustimm.
Die Exception sollte in der Factory geworfen werden - da kann sie auch evtl. präziser sein.
Der Test scheint mir daher auch sinnlos.

Der frühe Apfel fängt den Wurm.

Hallo,

danke für die vielen Antworten.

Ich fasse mal zusammen.

  1. ArgumentNullExcpetion macht sinn für Parameter (die null sind) um Aufrufer klar mitzuteilen was passiert ist.
  2. Beim Aufruf von anderen (außerhalb liegenden) Methoden, wie zum Beispiel in der Factory sollt die Factory einen Fehler schmeissen.

Gruß

Hallo lordbauer,

zu 1. Natürlich nur, wenn der jeweilige Parameter nicht null sein darf. Es gibt ja auch Methoden, bei denen es erlaubt ist, null zu übergeben. Da gibt dann weder eine ArgumentNullException noch eine NullReferenceExcpetion.

zu 2. Richtig, ArgumentNullExceptions sind nur über Parameter von Methoden (und vielleicht noch für den Parameter von Properties (value)). Wenn an anderen Stellen was null ist, was nicht null sein darf, muss man das anders behandeln (oder der CLR überlassen).

  1. Üblicherweise sollte man NullReferenceExceptions nicht explizit schmeißen, sondern dass der CLR überlassen.

  2. Beide Exceptions dienen dem leichteren Auffinden von Programmierfehlern. Beides Exceptions sind entsprechend normalerweise nicht dazu gedacht, um zur Laufzeit behandelt zu werden.

herbivore

  1. Beide Exceptions dienen dem leichteren Auffinden von Programmierfehlern. Beides Exceptions sind entsprechend normalerweise nicht dazu gedacht, um zur Laufzeit behandelt zu werden.

Sehe ich auch so.

Wenn man sich mal ne weile mit dem Exceptionhandling beschäftigt, stellt man fest, daß die Sache (scheinbar) oft extrem vernachlässigt wird. Man findet zwar überall Beispiele wie es prinizipiell funktioniert aber sehr wenig darüber wie man ein gutes Exceptionhandling-(Design) erstellt.

Danke für Eure Untersützung! 👍