Wir haben eine Eigenschaft, deren Aufgabe es ist, eine Beschreibung nachzuschlagen. Wenn die Suche fehlschlägt, sollte eine leere Zeichenfolge angezeigt werden.
So können wir die Eigenschaft wie folgt codieren:
%Vor%Aber das beinhaltet die Ausführung von foo.bar zweimal, und wenn das teuer ist, ist es wahrscheinlich besser so:
%Vor%Aber eigentlich wollen wir nur jede Art von Fehler als leere Beschreibung behandeln. In gewisser Weise ist das einfacher:
%Vor%Aber gibt es irgendwelche Probleme (Leistung, Reinheit, andere?) mit nur dem Fangen und dem Ignorieren des Fehlers?
Manchmal liest man, dass es teuer ist, eine Ausnahme auszulösen , aber ich bin nicht sicher, ob der Autor es teuer macht, Ausnahmen mit dem Throw -Schlüsselwort zu erstellen (was ich nicht mache) oder ob er es tut Das heißt, es ist teuer, Ausnahmen zuzulassen (wie ich es tun würde).
Ich würde definitiv auf Nothing testen, anstatt mich hier auf Ausnahmen zu verlassen. Der Code gibt an, dass das Szenario, in dem foo.bar Nothing ist, ein erwartetes Szenario und kein Ausnahme ist. Diese Art von gibt die Antwort.
Das Auslösen einer Ausnahme ist eine relativ teure Operation (aus Performance-Sicht). Dies ist unabhängig davon, ob Sie es in Ihren Code werfen oder ob es in den Bibliothekscode geworfen wird. Es ist genau die gleiche Operation. Ich würde jedoch nicht aus Leistungsgründen Ausnahmen aussetzen, es sei denn, ich hätte einen echten, gemessenen, kritischen Geschäftsfall.
Meiner Meinung nach ist das meistens eine Frage der Absicht; Indem Sie auf Nothing testen und sich darauf anmutig verhalten, drückt Ihr Code die Tatsache aus, dass dies keine merkwürdige Sache ist.
Wenn Sie sich Sorgen über die Leistung bei der Ausführung von foo.bar zweimal machen, müssen Sie zuerst herausfinden, ob das wirklich der Fall ist. Wenn ja, gibt es wahrscheinlich Möglichkeiten, das zu lösen (Ihr Codebeispiel enthält bereits einen Vorschlag).
Sie sollten immer versuchen, nichts zu testen, wenn Sie es als kontrollierten Zustand erwarten, verwenden Sie nur Fänge, wo es möglich ist, um unerwünschte Fehler zu behandeln (ich verwende unerwünscht breit, da einige Fehler gewünschte Ergebnisse erzeugen). Die Fähigkeit, Null-Strings zu behandeln, ohne eine Ausnahme zu fangen, ist dort, also benutze es.
Verwenden Sie eine leere String-Testfunktion innerhalb des String-Klassentyps IsNullOrEmpty oder IsNullOrWhiteSpace :
Damit können Sie Ihre Exception-Behandlung für unerwartete Ausnahmen verlassen (wie es sein sollte ^^)
Im Hinblick auf Ihre Auswahl ist die zweite der Empfehlung am nächsten, setzen Sie Ihr Funktionsergebnis in eine Holding-Variable und testen Sie diese Variable dann mit String.IsNullOrEmpt y oder wenn Sie die Whitespace-Überprüfung einfügen möchten, dann String.IsNullOrWhiteSpace (Dies gilt auch für leere Strings).
Hier ist der laufende Code:
Ich würde mit diesem Ansatz gehen:
%Vor%Wenn Sie später feststellen, dass Sie den gleichen Teil des Codes häufig wiederholen, können Sie diese Suche in eine generische Funktion wie die folgende umbrechen:
%Vor%Hier ist ein Anwendungsbeispiel:
%Vor%Es wird funktionieren, vorausgesetzt, Sie haben eine ähnliche Klasse im aktuellen Bereich deklariert:
%Vor%Was die Kosten für das Abfangen von Ausnahmen betrifft, hier ist ein Link zu meiner Antwort auf eine andere Frage . Es gibt Ihnen eine Vorstellung davon, wie sich das Einfangen der Ausnahme auf die Debugging-Leistung und die Ihres Release-Builds auswirkt. Semantisch vermeiden Sie besser das Auslösen von Ausnahmen, wenn es sich nicht um eine Ausnahme handelt, wie bereits in anderen Antworten erwähnt.
Tags und Links vb.net nullreferenceexception