streamalism.org

1. Oversigt

Fra og med foråret 5 har vi nu adgang til en interessant funktion, der hjælper os med at skrive en mere sikker kode. Denne funktion kaldes null-safety, en gruppe annoteringer, der fungerer som en sikkerhedsforanstaltning, der holder øje med potentielle null-referencer.

I stedet for at lade os slippe af sted med usikker kode, null-safety-funktionen producerer advarsler på kompileringstidspunktet. Sådanne advarsler kan forhindre katastrofale undtagelser med null pointer (NPE) ved kørsel.

2. Den @NonNull Kommentar

Det @NonNull annotering er den vigtigste blandt alle kommentarerne til null-safety-funktionen. Vi kan bruge denne kommentar til at erklære ikke-nul-begrænsning overalt, hvor en objektreference forventes: et felt, en metodeparameter eller en metodes returværdi.

Antag, at vi har en klasse, der hedder Person:

offentlig klasse person {privat streng fuldnavn; ugyldigt setFullName (streng fuldnavn) {if (fullName! = null && fullName.isEmpty ()) {fullName = null; } this.fullName = fuldnavn; } // getter}

Denne klassedefinition er gyldig, men har en defekt - fulde navn felt kan indstilles til nul. Hvis dette sker, kan vi ende med en NPE, når vi arbejder med fulde navn.

Spring null-safety-funktionen gør det muligt for værktøjer at rapportere en sådan fare. For eksempel, hvis vi skriver kode i IntelliJ IDEA og dekorerer fulde navn felt med @NonNull kommentar, vi får vist en advarsel:

Takket være denne indikation er vi opmærksomme på problemet på forhånd og er i stand til at træffe passende handlinger for at undgå en runtime fiasko.

3. Den @NonNullFields Kommentar

Det @NonNull annotering er nyttig til at garantere nul-sikkerhed. Vi forurener dog hele kodebasen, hvis vi pryder alle ikke-nul-felter med denne kommentar.

Vi kan undgå misbrug af @NonNull med endnu en kommentar - @NonNullFields. Denne kommentar gælder på pakkeniveau og underretter vores udviklingsværktøjer om, at alle felter i den kommenterede pakke som standard ikke er nul.

Til @NonNullFields anmærkning for at sparke ind, skal vi oprette en fil med navnet pakke-info.java i rodmappen på pakken og kommentere pakken med @NonNullFields:

@NonNullFields pakke org.baeldung.nullibility;

Lad os erklære en anden ejendom i Person klasse, kaldet kaldenavn:

pakke org.baeldung.nullibility; // importerklæringer public class Person {private String nickname; ugyldigt setNickName (@Nullable String nickname) {if (nickName! = null && nickName.isEmpty ()) {nickName = null; } dette. nickname = kaldenavn; } // andre erklæringer}

Denne gang pynter vi ikke på kaldenavn felt med @NonNull men stadig se en lignende advarsel:

Det @NonNullFields annotering gør vores kode mindre detaljeret, samtidig med at det samme sikkerhedsniveau sikres som @NonNull giver.

4. Den @Nullable Kommentar

Det @NonNullFields annotering foretrækkes generelt frem for @NonNull da det hjælper med at reducere kedelpladen. Til tider vil vi undtage nogle felter fra den ikke-nul-begrænsning, der er angivet på pakkeniveau.

Lad os gå tilbage til kaldenavn felt i og dekorere det med @Nullable kommentar:

@Nullable private String nickname;

Advarslen, vi så før, er væk nu:

I denne situation, vi brugte @Nullable kommentar for at tilsidesætte semantikken i @NonNullFields på et felt.

5. Den @NonNullApi Kommentar

Det @NonNullFields kommentar gælder kun for, som navnet antyder, felter. Hvis vi vil have den samme indflydelse på metodernes parametre og returværdier, har vi brug for det @NonNullApi.

Som med @NonNullFields, skal vi specificere @NonNullApi kommentar i pakke-info.java fil:

@NonNullApi-pakke org.baeldung.nullibility;

Lad os definere en getter til kaldenavn Mark:

pakke org.baeldung.nullibility; // importerklæringer offentlig klasse Person {@Nullable private String nickname; String getNickName () {return nickname; } // andre erklæringer}

Med @NonNullApi bemærkning i virkeligheden udsendes en advarsel om en mulig nul værdi produceret af getNickName metode:

Bemærk, at ligesom @NonNullFields kommentar, vi kan tilsidesætte @NonNullApi på metodeniveau med @Nullable kommentar.

6. Konklusion

Nul-sikkerhed i foråret er en fantastisk funktion, der hjælper med at mindske muligheden for NPE'er. Der er dog to vigtige punkter, vi skal passe på, når vi bruger denne funktion:

• Det kan kun bruges i et understøttende udviklingsværktøj, såsom IntelliJ IDEA
• Det håndhæves ikke nul kontrollerer ved kørsel - vi skal stadig selv skrive kode for at afværge NPE'er

Kildekoden til denne vejledning kan findes på GitHub.