streamalism.org

1. Inleiding

Onder de beslissingen die we nemen terwijl we onze applicaties schrijven, gaan er veel over wanneer we uitzonderingen moeten gooien en welk type we moeten gooien.

In deze korte tutorial gaan we het probleem aanpakken van de uitzondering die moet worden gegenereerd wanneer iemand een nul parameter naar een van onze methoden: IllegalArgumentException of NullPointerException.

We zullen het onderwerp verkennen door de argumenten voor beide partijen te onderzoeken.

2. IllegalArgumentException

Laten we eerst eens kijken naar de argumenten voor het gooien van een IllegalArgumentException.

Laten we een eenvoudige methode maken die een IllegalArgumentException wanneer geslaagd voor een nul:

public void processSomethingNotNull (Object myParameter) {if (myParameter == null) {throw new IllegalArgumentException ("Parameter 'myParameter' kan niet null zijn"); }}

Laten we nu verder gaan met de argumenten voor IllegalArgumentException.

2.1. Het is hoe de Javadoc het zegt te gebruiken

Toen we de Javadoc voor lazen IllegalArgumentException, het zegt het is voor gebruik wanneer een illegale of ongepaste waarde aan een methode wordt doorgegeven. We kunnen een nul bezwaar te maken illegaal of ongepast te zijn als onze methode dit niet verwacht, en dit zou een gepaste uitzondering voor ons zijn om te gooien.

2.2. Het komt overeen met de verwachtingen van ontwikkelaars

Laten we vervolgens eens nadenken over hoe wij, als ontwikkelaars, denken wanneer we stapelsporen in onze applicaties zien. Een veel voorkomend scenario waarin we een NullPointerException is wanneer we per ongeluk hebben geprobeerd toegang te krijgen tot een nul voorwerp. In dit geval gaan we zo diep mogelijk in de stapel om te zien waarnaar we verwijzen nul.

Als we een IllegalArgumentException, nemen we waarschijnlijk aan dat we iets verkeerds doorgeven aan een methode. In dit geval zoeken we in de stapel naar de onderste methode die we aanroepen en beginnen we vanaf daar met debuggen. Als we deze manier van denken overwegen, is de IllegalArgumentException gaat ons dichter bij de stapel brengen waar de fout wordt gemaakt.

2.3. Andere argumenten

Voordat we verder gaan met de argumenten voor NullPointerException, laten we eens kijken naar een paar kleinere punten ten gunste van IllegalArgumentException. Sommige ontwikkelaars zijn van mening dat alleen de JDK zou moeten gooien NullPointerException. Zoals we in de volgende sectie zullen zien, ondersteunt de Javadoc deze theorie niet. Een ander argument is dat het consistenter is om te gebruiken IllegalArgumentException aangezien dat is wat we zouden gebruiken voor andere illegale parameterwaarden.

3. NullPointerException

Laten we vervolgens eens kijken naar de argumenten voor NullPointerException.

Laten we een voorbeeld maken dat een NullPointerException:

public void processSomethingElseNotNull (Object myParameter) {if (myParameter == null) {throw new NullPointerException ("Parameter 'myParameter' kan niet null zijn"); }}

3.1. Het is hoe de Javadoc het zegt te gebruiken

Volgens de Javadoc voor NullPointerException, NullPointerException is bedoeld om te worden gebruikt om te proberen te gebruiken nul waar een object vereist is. Als onze methodeparameter niet bedoeld is nul, dan zouden we dit redelijkerwijs kunnen beschouwen als een object dat nodig is en de NullPointerException.

3.2. Het is consistent met JDK-API's

Laten we even nadenken over veel van de veelgebruikte JDK-methoden die we tijdens de ontwikkeling noemen. Velen van hen gooien een NullPointerException als we een nul. Bovendien, Objects.requireNonNull () gooit een NullPointerException als we passeren nul. Volgens de Voorwerpen documentatie, het bestaat voornamelijk voor het valideren van parameters.

Naast JDK-methoden die NullPointerExceptionkunnen we andere voorbeelden vinden van specifieke uitzonderingstypen die worden gegenereerd door methoden in de Collections API. ArrayList.addAll (index, verzameling) gooit een IndexOutOfBoundsException als de index buiten de lijstgrootte valt en een NullPointerException als de collectie is nul. Dit zijn twee zeer specifieke uitzonderingstypen in plaats van de meer algemene IllegalArgumentException.

We zouden kunnen overwegen IllegalArgumentException bedoeld voor gevallen waarin we geen specifieker uitzonderingstype tot onze beschikking hebben.

4. Conclusie

Zoals we in deze tutorial hebben gezien, is dit een vraag die geen duidelijk antwoord heeft. De documentatie voor de twee uitzonderingen lijkt te overlappen in die zin dat ze, als ze alleen worden genomen, allebei passend klinken. Er zijn ook aanvullende overtuigende argumenten voor beide partijen, gebaseerd op hoe ontwikkelaars hun foutopsporing uitvoeren en op patronen die te zien zijn in de JDK-methoden zelf.

Welke uitzondering we ook kiezen, we moeten consistent zijn in onze hele applicatie. Bovendien kunnen we onze uitzonderingen nuttiger maken door zinvolle informatie te verstrekken aan de uitzonderingsconstructor. Onze toepassingen zullen bijvoorbeeld gemakkelijker te debuggen zijn als we de parameternaam in het uitzonderingsbericht opgeven.

Zoals altijd is de voorbeeldcode beschikbaar op GitHub.