Ich sehe oft java SourceCode, wo eine Null als Wert für eine Methode oder einen Konstruktor nicht erlaubt ist. Eine typische Implementierung sieht so aus wie
%Vor% Ich sehe überhaupt keinen Sinn darin, denn wenn ich versuche, eine Methode auf einen NullPointer zu setzen, wird das NullPointerException trotzdem geworfen. Ich würde einen Sinn erkennen, wenn diese Methode eine IllegalArgumentException oder eine andere benutzerdefinierte Ausnahme auslösen würde. Kann jemand klarstellen, warum diese Überprüfung sinnvoll erscheint (da ich sehr oft davon ausgehe, dass dahinter Sinn liegt) oder warum es völliger Unsinn ist?
Der von Ihnen gepostete Code macht absolut keinen Sinn. Es sieht wie ein starker Fall von Cargokult-Programmierung aus. Höchstwahrscheinlich hat jemand einen nützlichen Test implementiert, um einmal nach den Bedingungen zu suchen und jemand anders hat den Test so angepasst, dass er so aussieht.
Nein, das macht nicht viel Sinn, aber nur, weil das Werfen einer NPE keine nützlichen Informationen hinzufügt.
Sie könnten den Fehler schöner machen, indem Sie zum Beispiel eine IllegalStateException werfen:
%Vor%Aber das fügt auch keinen großen Wert hinzu - abgesehen davon, dass es spezifisch ist was NULL ist (was bei komplexeren Methoden nützlich sein kann)
Natürlich möchten Sie nach Null suchen. Dies ist eine Voraussetzung für Ihre Methode, Teil des Vertrags mit den Kunden. Wenn Ihre Methode keine Nulleingabe akzeptieren kann, müssen Sie dies erzwingen.
Die Auswahl der Ausnahme könnte besser sein. Ich gehe normalerweise mit einem IllegalArgumentException .
Wenn es die Kürze der Methode ist, die Sie stört, muss ich sagen, ich stimme zu. Keine neuen Informationen dort.
Dies hängt davon ab, wer dafür verantwortlich ist, sich von dieser Situation zu erholen. Wenn es der Anrufer ist, werfen Sie eine NPE. Wenn es die aufgerufene Methode ist, testen Sie auf null und tun Sie alles, was notwendig ist, um die Situation zu lösen.
Bearbeiten: Werfen Sie eine NPE nicht explizit, sondern lassen Sie sie einfach platzen. Entschuldigung für die vagen Formulierungen.
Die von Ihnen beschriebene Situation kann unter einer der folgenden Annahmen nützlich sein:
1.) Wenn Sie einige Operationen durchführen müssen, die entweder kostspielig sind oder einen globalen Status vor der Ausführung someObject.aMethodCall() ändern, können Sie Rollback-Code und Verschwendung von Ausführungszyklen verhindern.
2.) Wenn someObject in einer Datenstruktur gespeichert ist, können Sie eine mögliche Fallstricke erzeugen, wenn zu einem späteren Zeitpunkt die Daten aus der Datenstruktur abgerufen werden. Ich denke, ich erinnere mich an einige Klassen im Java-Collection-Framework, die eher ein NPE werfen, als eine Null in die Speicherstruktur zu erlauben.
Persönlich ist der Grund, warum ich nie eine NullPointerException als Teil einer öffentlichen API-Methode werfen würde, weil es es für den Programmierer viel schwieriger macht, zwischen einem Programmierfehler auf seiner Seite und einem Fehler in meinem Code zu unterscheiden absichtlich zulassen, dass die NPE geworfen werden oder nicht?).
Das Werfen einer anderen Ausnahme macht die Absicht viel klarer und hilft dem Programmierer auch herauszufinden, was falsch ist. Also würde ich mit IllegalArgumentException dorthin gehen.
Wenn es eine interne Methode ist? Ich würde Behauptungen verwenden oder es einfach zum Absturz bringen. Es hat keinen Sinn, explizit ein NPE-Imo zu werfen.
Ich denke, diese Art der Überprüfung macht Sinn, wenn eine Methode eine Verarbeitung vornimmt, die viel Zeit in Anspruch nimmt oder schwer rückgängig zu machen ist, bevor sie tatsächlich die NPE auslöst. Im gegebenen Beispiel finde ich das nicht sinnvoll.
Andererseits kann es sinnvoller sein, assert zu verwenden oder eine spezifischere Ausnahme wie IllegalArgumentException auszulösen.
Tags und Links java nullpointerexception coding-style null