Vårens null-sikkerhetsmerknader

1. Oversikt

Fra og med våren 5 har vi nå tilgang til en interessant funksjon som hjelper oss med å skrive tryggere kode. Denne funksjonen kalles null-safety, en gruppe merknader som fungerer som en garanti som passer på potensielle null-referanser.

I stedet for å la oss slippe unna med usikker kode, null-sikkerhetsfunksjonen gir advarsler på kompileringstidspunktet. Slike advarsler kan forhindre katastrofale unntak for nullpeker (NPE) ved kjøretid.

2. Den @NonNull Kommentar

De @NonNull kommentar er den viktigste blant alle kommentarene til null-sikkerhetsfunksjonen. Vi kan bruke denne merknaden til å erklære ikke-null begrensning hvor som helst en objektreferanse forventes: et felt, en metodeparameter eller en metodes returverdi.

Anta at vi har en klasse som heter Person:

offentlig klasse Person {private String fullName; ugyldig setFullName (streng fullnavn) {if (fullName! = null && fullName.isEmpty ()) {fullName = null; } this.fullName = fullName; } // getter}

Denne klassedefinisjonen er gyldig, men har en mangel - fullt navn feltet kan settes til null. Hvis dette skjer, kan vi ende opp med en NPE når vi jobber med fullt navn.

Vårens null-sikkerhetsfunksjon gjør det mulig å rapportere en slik fare. For eksempel hvis vi skriver kode i IntelliJ IDEA og dekorerer fullt navn felt med @NonNull kommentar, vi får se en advarsel:

Takket være denne indikasjonen er vi klar over problemet på forhånd og er i stand til å iverksette passende tiltak for å unngå kjøretidsfeil.

3. Den @NonNullFields Kommentar

De @NonNull merknader er nyttige for å garantere null-sikkerhet. Imidlertid vil vi forurense hele kodebasen hvis vi pryder alle ikke-null-felt med denne kommentaren.

Vi kan unngå misbruk av @NonNull med en annen kommentar - @NonNullFields. Denne merknaden gjelder på pakkenivå, og informerer utviklingsverktøyene våre om at alle feltene i den merkede pakken som standard ikke er null.

For @NonNullFields merknad for å sparke inn, må vi opprette en fil med navnet pakkeinfo.java i rotkatalogen til pakken og kommentere pakken med @NonNullFields:

@NonNullFields pakke org.baeldung.nullibility;

La oss erklære en annen eiendom i Person klasse, kalt kallenavn:

pakke org.baeldung.nullibility; // importuttalelser offentlig klasse Person {private String nickname; ugyldig setNickName (@Nullable String nickname) {if (nickName! = null && nickName.isEmpty ()) {nickName = null; } dette. nickname = kallenavn; } // andre erklæringer}

Denne gangen pynter vi ikke på kallenavn felt med @NonNull men fremdeles se en lignende advarsel:

De @NonNullFields kommentar gjør koden vår mindre ordentlig, samtidig som den garanterer samme sikkerhetsnivå som @NonNull gir.

4. Den @Nullable Kommentar

De @NonNullFields merknader er generelt å foretrekke fremfor @NonNull da det bidrar til å redusere kjeleplaten. Noen ganger ønsker vi å frita noen felt fra den ikke-null begrensningen som er spesifisert på pakkenivå.

La oss gå tilbake til kallenavn felt i og dekorere det med @Nullable kommentar:

@Nullable private String nickname;

Advarselen vi så før er borte nå:

I denne situasjonen, vi brukte @Nullable kommentar for å overstyre semantikken til @NonNullFields på et felt.

5. Den @NonNullApi Kommentar

De @NonNullFields merknader gjelder bare felt, som navnet antyder. Hvis vi vil ha samme innvirkning på metodens parametere og returverdier, trenger vi @NonNullApi.

Som med @NonNullFields, må vi spesifisere @NonNullApi kommentar i pakkeinfo.java fil:

@NonNullApi-pakke org.baeldung.nullibility;

La oss definere en getter for kallenavn felt:

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

Med @NonNullApi merknad i kraft, utstedes en advarsel om en mulig null verdien produsert av getNickName metode:

Legg merke til at akkurat som @NonNullFields kommentar, vi kan overstyre @NonNullApi på metodenivå med @Nullable kommentar.

6. Konklusjon

Spring null-safety er en flott funksjon som hjelper til med å redusere muligheten for NPE. Imidlertid er det to viktige punkter vi må passe oss når vi bruker denne funksjonen:

  • Den kan bare brukes i et støttende utviklingsverktøy, for eksempel IntelliJ IDEA
  • Det håndheves ikke null sjekker ved kjøretid - vi trenger fortsatt å skrive kode selv for å avverge NPEer

Kildekoden for denne veiledningen finner du på GitHub.