Java: vermeiden Sie null-in geschachtelten Klassen (Tief-Null-Prüfung)
Vorstellen, habe ich eine Klasse Familie. Es enthält eine Liste von Personen. Jede (Klassen -) Person enthält (Klasse) - Adresse. Jede (Klassen -) Adresse enthält (Klasse) PLZ. Alle "zwischen" - Klasse kann null sein.
So, gibt es eine einfache Methode, um PostalCode ohne vorher zu prüfen, für die null in jedem Schritt? also, gibt es eine Möglichkeit zu vermeiden, die folgenden daisy-chaining-code? Ich weiß, es ist nicht "native" Java-Lösung, aber hatte gehofft, wenn jemand weiß, eine Bibliothek oder so etwas. (geprüft Commons & Guave und nicht alles sehen)
if(family != null) {
if(family.getPeople() != null) {
if(family.people.get(0) != null) {
if(people.get(0).getAddress() != null) {
if(people.get(0).getAddress().getPostalCode() != null) {
//FINALLY MADE IT TO DO SOMETHING!!!
}
}
}
}
}
Nein, können nicht ändern die Struktur. Es ist ein service, den ich nicht kontrollieren.
Nein, ich kann nicht mit Groovy und es ist praktisch "Elvis" - operator.
Nein, ich würde es vorziehen, nicht zu warten, bis Java 8 😀
Ich kann nicht glauben, ich bin der erste dev jemals krank 'n müde, Sie code schreiben, wie diese, aber ich habe nicht in der Lage, eine Lösung zu finden.
Ideen?
Dank
--
llappall
- Sorry, du bist zu stecken. Einige Leute benutzen den trinary bedingte operator, um es ein wenig weniger dicht, aber es ist immer noch der gleiche bytecode, nur schwerer zu Lesen.
- "Ich kann nicht glauben, ich bin der erste dev jemals krank 'n müde von schreiben von code wie dieser" Nun, das sind Sie nicht.
- Sicher. Aber ich glaube nicht, dass Sie können mehr beaty den code! Sorry!
- Trotz all der Antworten, die sagen, Sie ignorieren null-Prüfungen und versuchen Sie einfach zu fangen
NullPointerException
, tun Sie es nicht! Ihr code möglicherweise ein Dorn im Auge, aber eine Ausnahme ist, eine teure operation, die Sie wollen immer zu vermeiden, wenn Sie können. - Bedenken Sie auch, all die guten Dinge, die Sie tun können, im "else" - Klauseln, wenn Sie Sie in Platz - error-messaging, alternativen code-Pfade, etc. Angesichts all das, es wird nicht so schlimm.
- Wenn nur Sie könnten port Brototype für Java - ... github.com/letsgetrandy/brototype
Du musst angemeldet sein, um einen Kommentar abzugeben.
Dein code verhält sich wie
Dank Kurzschluss-Auswertung, das ist auch sicher, da die zweite Bedingung wird nicht evaluiert, wenn die erste false ist, wird die 3. wird nicht ausgewertet, wenn das 2. ist falsch,.... und werden Sie nicht bekommen, NPE, weil wenn es.
null
immer bleiben wollen in unsere codes!Die nächstgelegene Sie bekommen können, um die Vorteile der short-cut-Regeln-Bedingungen:
Durch die Art und Weise, dass man eine Ausnahme statt testen der Bedingung im Voraus ist eine schreckliche Idee.
}
es (vergessen, Sie zu entfernen, wenn umgestalteten)Wenn es selten ist, könnten Sie ignorieren die
null
überprüft und beruhen aufNullPointerException
. "Selten" ist aufgrund möglicher performance-problem (hängt davon ab, in der Regel füllen, die in der stack-trace, das kann teuer werden).Anderes, als dass 1) ein bestimmtes Helfer-Methode, die prüft, für null zu bereinigen, die code oder Machen 2) generischer Ansatz mit der spiegelung und eine Zeichenfolge wie:
Umsetzung als übungsaufgabe.
Nicht so eine Coole Idee, aber wie wäre es, die exception zu fangen:
Können Sie verwenden für:
optional äquivalent:
Statt mit null, Sie könnte verwenden eine version des "null-object" - Entwurfsmuster. Zum Beispiel:
Dann deine if-Anweisung werden können:
Es ist suboptimal, da:
Aber wenn Sie wirklich hassen Ihren
== null
s, ist dies ein Ausweg.Ich war gerade auf der Suche für die gleiche Sache (mein Kontext: eine Reihe von automatisch erstellten JAXB-Klassen, und irgendwie habe ich diese lange Verkettungen von
.getFoo().getBar()...
. Immer, sobald in einem, während einer der Anrufe, die in der Mitte null zurück, wodurch der NPE.Etwas, was ich begann das hantieren mit einer Weile zurück, beruht auf Reflexion. Ich bin sicher, wir können diese schöner und effizienter (caching der Reflexion, für eine Sache, und auch die Definition "Magische" Methoden wie
._all
automatisch die Iteration über alle Elemente einer Sammlung sind, wenn eine Methode, in der Mitte gibt eine collection zurück). Nicht schön, aber vielleicht hat jemand könnte uns sagen, ob es schon was besseres gibt:Dann, wenn im Falle, Sie sind mit java8 dann können Sie verwenden;
REF: vermeiden Sie null-Prüfungen
Obwohl dieser post ist schon fast fünf Jahre alt, vielleicht habe ich eine andere Lösung, um die uralte Frage, wie das zu handhaben
NullPointerException
s.Kurz gesagt:
Da gibt es eine Menge von legacy-code noch im Einsatz, die mit Java 8 und
Optional
ist nicht immer eine option.Immer, wenn es tief verschachtelten Klassen beteiligt (JAXB, SOAP, JSON, you name it...) und Gesetz von Demeter nicht angewendet, Sie haben im Grunde alles überprüfen und sehen, ob es möglich NPEs lauert.
Meine vorgeschlagene Lösung strebt readibility und sollte nicht verwendet werden, wenn es nicht mindestens 3 oder mehr geschachtelte Klassen beteiligt (wenn ich sage, verschachtelte, ich meine nicht Geschachtelte Klassen in der formalen Kontext). Da der code ist mehr zu Lesen als es geschrieben ist, ein kurzer Blick in den linken Teil des Codes wird Ihre Bedeutung klarer als die Verwendung von tief verschachtelten if-else-Anweisungen.
Wenn Sie brauchen, wird der else-Teil, können Sie mit diesem Muster:
Bestimmte IDEs bricht diese Formatierung, wenn Sie Sie anweisen, nicht zu (siehe diese Frage).
Ihre Bedingungen müssen invertiert werden - Sie sagen, der code, wenn es brechen sollte, nicht, wenn es fortgesetzt werden soll.
Noch eins - dein code ist immer noch anfällig für Bruch. Müssen Sie
if(family.getPeople() != null && !family.getPeople().isEmpty())
als erste Zeile in Ihrem code sein, ansonsten wird eine leere Liste wirft eine NPE.und mein Favorit, der einfach try/catch, um zu vermeiden, verschachtelte null Kontrollen...