streamalism.org

1. Introduktion

Blandt de beslutninger, vi tager, når vi skriver vores ansøgninger, handler mange om, hvornår undtagelser skal kastes, og hvilken type der skal kastes.

I denne hurtige vejledning skal vi tackle spørgsmålet om, hvilken undtagelse der skal kastes, når nogen passerer en nul parameter til en af ​​vores metoder: IllegalArgumentException eller NullPointerException.

Vi undersøger emnet ved at undersøge argumenterne for begge sider.

2. IllegalArgumentException

Lad os først se på argumenterne for at kaste en IllegalArgumentException.

Lad os oprette en enkel metode, der kaster en IllegalArgumentException når bestået a nul:

public void processSomethingNotNull (Object myParameter) {if (myParameter == null) {throw new IllegalArgumentException ("Parameter 'myParameter' kan ikke være null"); }}

Lad os nu gå videre til argumenterne til fordel for IllegalArgumentException.

2.1. Sådan siger Javadoc at bruge det

Når vi læser Javadoc for IllegalArgumentException, det siger det er til brug, når en ulovlig eller upassende værdi overføres til en metode. Vi kan overveje en nul gør indsigelse mod at være ulovligt eller upassende, hvis vores metode ikke forventer det, og dette ville være en passende undtagelse for os at kaste.

2.2. Det matcher udviklerens forventninger

Lad os derefter tænke over, hvordan vi som udviklere tænker, når vi ser stakspor i vores applikationer. Et meget almindeligt scenario, hvor vi modtager en NullPointerException er når vi ved et uheld har forsøgt at få adgang til en nul objekt. I dette tilfælde vil vi gå så dybt ind i stakken som vi kan for at se, hvad vi henviser til det nul.

Når vi får en IllegalArgumentException, antager vi sandsynligvis, at vi videregiver noget forkert til en metode. I dette tilfælde ser vi i stakken efter den nederste metode, vi kalder på, og starter vores fejlretning derfra. Hvis vi overvejer denne måde at tænke på, IllegalArgumentException vil bringe os ind i vores stak tættere på, hvor fejlen begås.

2.3. Andre argumenter

Før vi går videre til argumenterne for NullPointerException, lad os se på et par mindre punkter til fordel for IllegalArgumentException. Nogle udviklere føler, at kun JDK skal kaste NullPointerException. Som vi vil se i det næste afsnit, understøtter Javadoc ikke denne teori. Et andet argument er, at det er mere ensartet at bruge IllegalArgumentException da det er det, vi ville bruge til andre ulovlige parameterværdier.

3. NullPointerException

Lad os derefter overveje argumenterne for NullPointerException.

Lad os oprette et eksempel, der kaster en NullPointerException:

public void processSomethingElseNotNull (Object myParameter) {if (myParameter == null) {throw new NullPointerException ("Parameter 'myParameter' kan ikke være null"); }}

3.1. Sådan siger Javadoc at bruge det

Ifølge Javadoc for NullPointerException, NullPointerException er beregnet til at blive brugt til forsøg på at bruge nul hvor der kræves et objekt. Hvis vores metodeparameter ikke er beregnet til at være nul, så kunne vi med rimelighed betragte dette som et objekt, der kræves, og kaste NullPointerException.

3.2. Det er i overensstemmelse med JDK API'er

Lad os tage et øjeblik til at tænke over mange af de almindelige JDK-metoder, vi kalder under udviklingen. Mange af dem kaster en NullPointerException hvis vi leverer en nul. Derudover Objects.requireNonNull () kaster en NullPointerException hvis vi passerer ind nul. Ifølge Objekter dokumentation, den findes hovedsagelig til validering af parametre.

Ud over JDK-metoder, der kaster NullPointerException, kan vi finde andre eksempler på, at specifikke undtagelsestyper kastes fra metoder i Collections API. ArrayList.addAll (indeks, samling) kaster en IndexOutOfBoundsException hvis indekset er uden for listestørrelsen og kaster et NullPointerException hvis samlingen er nul. Disse er to meget specifikke undtagelsestyper snarere end de mere generiske IllegalArgumentException.

Vi kunne overveje IllegalArgumentException at være beregnet til tilfælde, hvor vi ikke har en mere specifik undtagelsestype tilgængelig for os.

4. Konklusion

Som vi har set i denne vejledning, er dette et spørgsmål, der ikke har et klart svar. Dokumentationen for de to undtagelser synes at overlappe hinanden, at når de tages alene, lyder de begge passende. Der er også yderligere overbevisende argumenter for begge sider baseret på, hvordan udviklere foretager deres fejlretning og på mønstre, der ses i JDK-metoderne selv.

Uanset hvilken undtagelse vi vælger, skal vi være konsekvente i hele vores ansøgning. Derudover kan vi gøre vores undtagelser mere nyttige ved at give meningsfuld information til undtagelseskonstruktøren. For eksempel vil vores applikationer være nemmere at debugge, hvis vi angiver parameternavnet i undtagelsesmeddelelsen.

Som altid er eksempelkoden tilgængelig på GitHub.