Posts Tagged ‘NPE’

NPE’s, nullables, not-nulls and commons

april 28, 2009

Iedereen maakt ze vast nog wel wekelijks mee: NullPointerExceptions. In sommige gevallen ligt dat aan de slechte routine(s) van de ontwikkelaar, maar vaak aan de methodes doordat je niet direct kunt zien welke argumenten null mogen zijn en of het mogelijk null teruggeeft.
Door je code wat handiger op te zetten, kun je al een deel van deze NPE’s voorkomen. Als we beginnen met equals vergelijkingen, zorg er dan voor dat je begint met de constante en niet met de variabele. Vergelijk bijvoorbeeld "excellent".equals(comparisson); met comparisson.equals("bad");
Van comparisson is niet te voorspellen wat de waarde is, het zou eventueel null kunnen zijn. Door te beginnen met de constante kan er geen NPE ontstaan. Deze volgorde zie je ook terug bij de assert-methodes van JUnit. Daarin geef je eerst de expected waarde op (de constante), gevolgd door de uitkomst van een methode of variabele.
Het kan natuurlijk voorkomen dat je twee variabelen wilt vergelijken. In dat geval biedt commons-lang uitkomst. Commons-lang bevat een aantal utility-classes, welke voornamelijk null-safe zijn. Voor het vergelijken van objecten kun je gebruik maken van org.apache.commons.lang.ObjectUtils.equals(java.lang.Object object1, java.lang.Object object2). Deze methode vergelijkt de objecten en geeft 'true' terug als beide objecten gelijk of beide null zijn. Voor uitgebreidere String-vergelijkingen kun je gebruik maken van de StringUtils.

Hiermee is al de meeste pijn verzacht. Maar toch zou het handig zijn als je aan de methode kon zien (of bepalen) dat de mee te geven argumenten niet null mogen zijn en of het eventueel null kan retourneren. Kortgeleden viel mijn oog op een artikel aan van Stephen Colebourne. Daarin wordt het nullable-probleem netjes uiteengezet inclusief een oplossing of voorstel hiervoor. Annotations als @nullable en @notnull zien er elegant uit, maar kunnen nog steeds niet voorkomen, dat je tijdens het compileren gewaarschuwd dan wel afgestrafd wordt. Persoonlijk voel ik niet zoveel voor een ‘#’ als marker, maar meer voor een nieuw reserved word als bijvoorbeeld notnull. Het zou in ieder geval een enorme aanwinst zijn als de javacompiler met deze functionaliteit wordt uitgebreid.

Tot op zekere hoogte zou de java-compiler geinstrueerd kunnen worden om null-waarden af te vangen, maar daarmee kan slechts een deel van de NPE’s voorkomen worden. Developers zullen altijd in hun code rekening moeten houden met potentiele NPE’s, want bij bijna elke punt maak je weer kans om in de prijzen te vallen. Door¬†vergelijkingen slimmer te definieren en door gebruik te maken van null-safe utilities zoals grotendeels in commons-lang en commons-collections is de kans op deze veel voorkomende error aanzienlijk geslonken. Zo zie je maar: met wat kleine aanpassingen kun je je code al snel stabieler krijgen.

Advertenties