Ned med NULL!

Det er almindeligt i mange programmeringssprog, at alle pointere og objektreferencer kan være nulreferencer (null pointers). Det har nogle fordele:

• I hægtede strukturer såsom lister og træer, kan en nulreference bruges som den tomme liste eller det tomme træ.

• En nulreference kan bruges som fejlværdi: Hvis en funktion ikke kan returnere en "rigtig" værdi, returnerer den en nulreference.

Men det er heller ikke uden problemer:

• Alle referencer kan potentielt være nulreferencer, så der skal checkes for dette overalt. Det bliver ofte glemt, og det kan tage meget test at finde manglende null-checks. Så man betaler for bekvemmelighed spredte steder i koden med ubekvemmelighed og potentiel usikkerhed alle andre steder.
• Hvis en nulreference bruges som tom liste o.lign., så bliver man nødt til at angive fejlværdier anderledes, så at bruge nulreferencer som "standardmetoden" til angivelse af fejlværdier er ikke nogen god ide.

Derfor synes jeg, at implicitte nulreferencer i alle referencetyper bør afskaffes. Der er bedre måder at indikere fejl – enten ved undtagelser (exceptions) eller ved at bruge en type, der eksplicit kan være en fejlværdi eller en normal værdi (og når først man har checket for det, kan kan bruge normalværdien i kontekster, hvor der ikke checkes for fejlværdier). C# 2.0 indførte netop den sidstnævnte slags værdier i form af nullable types, der trods navnet ikke er det samme som implicitte nulreferencer i alle referencetyper (som er det, jeg opponerer mod).

Så referencetyper skal ikke have nulreferencer (og det skal verificeres af oversætteren), men alle typer skal have mulighed for at blive udstyret med et eksplicit fejlelement, og det skal være forholdsvis nemt at konvertere mellem typer med og uden fejlelementer.

Der findes en variant af C# kaldet Spec#, som bruger denne ide. Spec# har også mange andre gode ideer, såsom kontrakter, der checkes af oversætteren, så man ikke behøver at teste dem bagefter.

Men ideen er ikke ny. F.eks. har Standard ML aldrig haft nulreferencer. Undtagelser har været med fra starten, og enhver type kan udvides til at være en option-type, der enten er værdien NONE eller en almindelig værdi. Option-typer bliver i de fleste SML-oversættere implementeret som enten en nulreference eller en ikke-nulreference til en værdi, så der er ikke mistet noget effektivitet i forhold til de implicitte nulreferencer – tværtimod, for hvor f.eks. JVM og .NET checker for nulreferencer på køretid, hver gang man følger en reference, så kan disse checks undgås i SML, da oversætteren garanterer, at referencen ikke er nul. Desværre kan man ikke udnytte denne garanti, hvis SML oversættes til JVM eller .NET, da designerne af disse virtuelle maskiner ikke havde fantasi nok til at forestille sig, at man statisk (ret nemt) kan garantere, at refererencer aldrig kan være nul.