streamalism.org

1. Introduksjon

Blant avgjørelsene vi tar når vi skriver søknadene våre, handler mange om når du skal kaste unntak og hvilken type du skal kaste.

I denne raske opplæringen skal vi takle problemet med hvilket unntak vi skal kaste når noen passerer en null parameter til en av metodene våre: IllegalArgumentException eller NullPointerException.

Vi vil utforske emnet ved å undersøke argumentene for begge sider.

2. IllegalArgumentException

La oss først se på argumentene for å kaste en IllegalArgumentException.

La oss lage en enkel metode som kaster en IllegalArgumentException når passert a null:

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

La oss nå gå videre til argumentene til fordel for IllegalArgumentException.

2.1. Det er hvordan Javadoc sier å bruke det

Når vi leser Javadoc for IllegalArgumentException, det står det er til bruk når en ulovlig eller upassende verdi overføres til en metode. Vi kan vurdere en null innvende mot å være ulovlig eller upassende hvis vår metode ikke forventer det, og dette ville være et passende unntak for oss å kaste.

2.2. Det samsvarer med utviklerens forventninger

La oss så tenke på hvordan vi, som utviklere, tenker når vi ser stabelspor i applikasjonene våre. Et veldig vanlig scenario der vi mottar en NullPointerException er når vi ved et uhell har prøvd å få tilgang til en null gjenstand. I dette tilfellet skal vi gå så dypt inn i bunken som mulig for å se hva vi refererer til null.

Når vi får en IllegalArgumentException, antar vi sannsynligvis at vi gir noe galt til en metode. I dette tilfellet ser vi i bunken etter den nederste metoden vi kaller, og starter feilsøkingen derfra. Hvis vi vurderer denne tankegangen, vil IllegalArgumentException kommer til å få oss inn i stakken vår nærmere feilen blir gjort.

2.3. Andre argumenter

Før vi går videre til argumentene for NullPointerException, la oss se på et par mindre poeng til fordel for IllegalArgumentException. Noen utviklere føler at bare JDK skal kaste NullPointerException. Som vi vil se i neste avsnitt, støtter ikke Javadoc denne teorien. Et annet argument er at det er mer konsistent å bruke IllegalArgumentException siden det er det vi vil bruke til andre ulovlige parameterverdier.

3. NullPointerException

La oss deretter vurdere argumentene for NullPointerException.

La oss lage et eksempel som kaster a NullPointerException:

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

3.1. Det er hvordan Javadoc sier å bruke det

I følge Javadoc for NullPointerException, NullPointerException er ment å brukes til å prøve å bruke null der det kreves et objekt. Hvis metodeparameteren vår ikke er ment å være null, så kunne vi med rimelighet vurdere dette som et objekt som kreves og kaste NullPointerException.

3.2. Det samsvarer med JDK APIer

La oss ta et øyeblikk og tenke på mange av de vanlige JDK-metodene vi kaller under utviklingen. Mange av dem kaster en NullPointerException hvis vi gir en null. I tillegg Objects.requireNonNull () kaster en NullPointerException hvis vi passerer inn null. Ifølge Objekter dokumentasjon, eksisterer den hovedsakelig for validering av parametere.

I tillegg til JDK-metoder som kaster NullPointerException, kan vi finne andre eksempler på at spesifikke unntakstyper kastes fra metoder i Collections API. ArrayList.addAll (indeks, samling) kaster en IndexOutOfBoundsException hvis indeksen er utenfor listestørrelsen og kaster a NullPointerException hvis samlingen er null. Dette er to veldig spesifikke unntakstyper i stedet for de mer generiske IllegalArgumentException.

Vi kan vurdere IllegalArgumentException å være ment for tilfeller der vi ikke har en mer spesifikk unntakstype tilgjengelig for oss.

4. Konklusjon

Som vi har sett i denne opplæringen, er dette et spørsmål som ikke har et klart svar. Dokumentasjonen for de to unntakene ser ut til å overlappe hverandre når de tas alene, de høres passende ut. Det er også flere overbevisende argumenter for begge sider basert på hvordan utviklere gjør feilsøking og på mønstre sett i JDK-metodene selv.

Uansett hvilket unntak vi velger, bør vi være konsistente gjennom hele søknaden. I tillegg kan vi gjøre unntakene mer nyttige ved å gi meningsfull informasjon til unntakskonstruktøren. For eksempel vil programmene våre være lettere å feilsøke hvis vi oppgir parameternavnet i unntaksmeldingen.

Som alltid er eksempelkoden tilgjengelig på GitHub.