Die im Projekt aufgetretene NullPointerException ist in zwei Situationen unterteilt:
1. Referenzieren Sie das leere Objekt, dh rufen Sie die Methode des leeren Objekts auf oder verweisen Sie auf die Eigenschaften des leeren Objekts.
2. Ordnen Sie die Kapselungsklassen der Grundtypen in 8 den entsprechenden Grundklassen zu.
1. Wir müssen nicht null Urteile über die von den Schnittstellen anderer Personen zurückgegebenen Objekte fällen, da wir nicht wissen, ob die erhaltenen Objekte leer sind. Für Collection Map rufe ich normalerweise CollectionUtils MapUtils auf ruft StringUtils.isNotEmpty( ) auf, um eine nicht leere Beurteilung durchzuführen. Unter diesen beurteilt isNotEmpty nicht nur NULL, sondern auch leere Mengen und leere Zeichenfolgen. Fragen Sie beispielsweise Ergebnisse aus Daten ab. Im Workflow zurückgegebene Preis-URL
2. Bei den von Ihnen erstellten Objekten sollten Sie darauf achten, welche Operationen das Objekt ausführt und ob das Objekt in der Mitte leer ist. Fügen Sie nach Möglichkeit eine Nicht-Null-Beurteilung hinzu, insbesondere bei Sammlungsoperationen, die leicht zu melden sind ein Nullzeiger! ! ! Deshalb werde ich jedes Mal, wenn ich eine Sammlung betreibe, sehr vorsichtig sein.
3. Seien Sie sehr vorsichtig mit den Feldobjekten im Vordergrund, da diese Objekte vom Framework erstellt werden. Wenn ich im Vordergrund keinen Wert in das Textfeld eingebe, erhält das Backend beim Senden eine leere Zeichenfolge von NullPointerException ist sehr hoch.
4. Versuchen Sie für String-Operationen, die StringUtils-Klasse von Apache zu verwenden. Dies ist im Vergleich zu String sehr sicher. Verwenden Sie für Sammlungsvorgänge die CollectionUtils und MapUtils von Apache. Im Vergleich zu den Apache-Toolklassen ist die Ausführungseffizienz ebenfalls sehr hoch, z. B. StringUtils.split();
Einige Leute sagen, dass zu viel Urteilsvermögen die Leistung beeinträchtigt. Ich persönlich denke, dass die Leistungseinbußen hier im Vergleich zur Sicherheit des Systems vernachlässigbar sind.