Return null; er et alt for ofte brugt statement (i Java i hvert fald).
NÃ¥r der i en metode stÃ¥r “return null;”, er det oftest fordi, man er røget i et eller andet specialtilfælde, hvor metoden ikke har noget fornuftigt at returnere, men det er alligevel ikke sÃ¥ alvorligt, at der skal kastes en exception.
Det er i hvert fald det, jeg ser mest.
Men som regel er det i mine øjne ikke det bedste valg at returnere null. Det er nemlig problematisk, fordi man fÃ¥r utroligt meget kode, som skal tage højde for, at returværdier kan være null – og det er ofte fuldstændigt udokumenteret, hvornÃ¥r en metode returnerer null. Rigtigt slemt bliver det, nÃ¥r en metode i flere forskellige tilfælde kan returnere null – hvordan skal man hÃ¥ndtere det?
Hvis man glemmer at kontrollere returværdier for, om de er null, står man pludselig med fejl, og tester man alle returværdier, står man pludselig med en hel masse kode, som udelukkende tester for null.
Man kan dog vælge at lave helpermetoder, som foretager null-tests. Det kan gøres vha. generics (i hvert fald i Java); det kan gøres på relativt få linier kode, men det er til gengæld med til at give et ekstra lag af kompleksitet.
En langt bedre løsning er i min optik, at man som udvikler rent faktisk gør sig den ulejlighed, at man bruger “return null;” sÃ¥ lidt som muligt og i stedet for tænker over, hvad man kan returnere, hvis der ikke er noget at returnere. Det lyder lidt tosset, men f.eks. er en tom liste bedre at returnere end null, hvis man ikke kan finde det, som metoden er blevet bedt om at finde.
Der er sÃ¥gar et design pattern, som beskæftiger sig med dette – Null Object Pattern.
Naturligvis kan det nogle gange give god mening at returnere null, og i de tilfælde skal man selvfølgelig returnere null. Men langt henad vejen vil jeg mene, at null er det helt forkerte at returnere.














