neuen Exception vs Catch-Block werfen

Nein, Console.WriteLine(null) wird keine Ausnahme auslösen. Es wird nur nichts ausgedruckt. Nun vorausgesetzt, du meintest so etwas wie:

dann macht es Sinn ... und Sie sollten die erste Form verwenden. Ausnahmen sollten auftreten, wenn Sie sie nicht im Voraus mit Ihren aktuellen Informationen vorhersagen können. Wenn Sie leicht herausfinden können, dass etwas nicht stimmt, ist es nicht sinnvoll, eine Operation zu versuchen, die zwangsläufig fehlschlägt. Es führt zu Code, der schwerer zu verstehen ist und schlechter abschneidet.

Also NullReferenceException , ArgumentNullException und ähnliches sollten nicht abgefangen werden, es sei denn, sie sind aufgrund eines nasty API, die manchmal Ausnahmen wirft, die Sie behandeln können, die aber nicht wirklich an erster Stelle geworfen werden sollten . In Code Contracts besteht das Standardverhalten für einen fehlgeschlagenen Vertrag daher darin, eine Ausnahme auszulösen, die nicht kann, außer indem alles abgefangen wird (was normalerweise der Fall ist) irgendwo an der Spitze des Stapels).

Wie schon von Jon Skeet erwähnt, wird Console.WriteLine (null) keine Ausnahme auslösen.

Außerdem möchte ich sagen, dass Sie "schnell scheitern" sollten. Das bedeutet, dass Sie Guard-Klauseln in Ihre Methoden schreiben müssen und die Argumente überprüfen müssen, die in Ihren Methoden angegeben wurden, wenn sie als gültig angesehen werden können. Dadurch können Sie selbst eine Ausnahme auslösen und eine zusätzliche Nachricht geben, die Ihnen beim Debuggen behilflich sein wird. Die Nachricht kann einen deutlichen Hinweis darauf geben, was falsch war, und das ist viel handlicher, wenn Sie mit einer NullReferenceException konfrontiert werden, die ohne eine gute Information in der Nachrichteneigenschaft der Nachricht ausgelöst wurde.

Wenn Sie eine Klassenbibliothek schreiben, kann es vorkommen, dass Sie wissen, dass ein bestimmter Parameter, der einen Nullwert enthält, später Probleme verursachen kann. In diesen Fällen halte ich es für eine gute Idee, eine Exception auszulösen (obwohl ich wahrscheinlich ArgumentNullException für diesen Fall verwenden würde), um den Benutzer der Klassenbibliothek so früh und klar wie möglich darauf aufmerksam zu machen.

Ausnahmen sind nicht immer eine schlechte Sache.

Jon Skeet hat recht, aber im Allgemeinen ist alles eine Frage der Semantik.

Wenn die Situation eine anwendbare Bedeutung hat (Zahl außerhalb des Gebietes, Geburtsdatum in der Zukunft, usw.), möchten Sie vielleicht vor jeder Operation einen Test durchführen und eine benutzerdefinierte Ausnahme (mit Bedeutung für Ihre Anwendung) auslösen ).

Wenn die Situation wirklich "außergewöhnlich" ist, schreiben Sie den Code so, als wäre der angegebene Wert korrekt. Sehen Sie, wenn Sie den Test setzen, werden Sie es jedes Mal tun, wissend, dass die VM es trotzdem tun wird, falls es eine Ausnahme auslösen muss. Unter dem Gesichtspunkt der Leistung, wenn der Fehler zufällig ein statistisch kleines Vorkommen hat, macht es keinen Sinn.

Wenn Sie einen Design-by-Contract-Ansatz für Dinge verwenden, kann ein Codeabschnitt angeben, dass er Ausnahmen auslöst, um seinen Vertrag festzulegen und ihn durchzusetzen. Die andere Hälfte nennt natürlich den Code, der den Vertrag anerkennt und erfüllt.

In diesem Fall würde es bedeuten, dass wenn Sie wissen, dass eine Methode eine Ausnahme auslöst, wenn Sie Null übergeben (d. h. ihr Vertrag besagt, dass Sie Nullen nicht übergeben), sollten Sie vor dem Aufruf überprüfen.

Jon Skeet sagt, dass die Methode sowieso keine Ausnahme auslöst. Das mag wahr sein oder auch nicht, aber das Prinzip der Bewachung für Methodenverträge steht (was ich glaube, war der Punkt Ihrer Frage).