---
title: 'null/NullPointerException in anderen Programmiersprachen: Ruby, nil, Scala, Option, None, Some'
url: 'https://www.tutego.de/blog/javainsel/2010/07/nullnullpointerexception-in-anderen-programmiersprachen-ruby-nil-scala-option-none-some'
markdown: 'https://www.tutego.de/blog/javainsel/2010/07/nullnullpointerexception-in-anderen-programmiersprachen-ruby-nil-scala-option-none-some.md'
date: '2010-07-24'
description: 'Ist Java eine pure objektorientiere Programmiersprache? Nein, da Java einen Unterschied zwischen primitiven Typen und Referenztypen macht. Nehmen wir für einen Moment an, dass es primitive Typen nicht gibt. Wäre Java dann eine reine objektorientierte Programmiersprache, bei der jede Referenz ein pu…'
taxonomy:
  category:
    - Insel
---

# null/NullPointerException in anderen Programmiersprachen: Ruby, nil, Scala, Option, None, Some

![Illustration einer tropischen Insel mit Palmen und einem hohen Berg](https://www.tutego.de/blog/javainsel/user/themes/tutego/images/insel-cover.jpg)# Java Blog für Programmierer

[Java Blog für Programmierer](https://www.tutego.de/blog/javainsel/)

## null/NullPointerException in anderen Programmiersprachen: Ruby, nil, Scala, Option, None, Some

24.07.2010 · [Christian Ullenboom](https://www.tutego.de/blog/javainsel/author/admin/)

Ist Java eine pure objektorientiere Programmiersprache? Nein, da Java einen Unterschied zwischen primitiven Typen und Referenztypen macht. Nehmen wir für einen Moment an, dass es primitive Typen nicht gibt. Wäre Java dann eine reine objektorientierte Programmiersprache, bei der jede Referenz ein pures Objekt referenziert? Die Antwort ist immer noch nein, da es mit `null` etwas gibt, mit dem Referenzvariablen initialisiert werden können, aber was kein Objekt repräsentiert und keine Methoden besitzt. Und das kann bei der Dereferenzierung eine `NullPointerException` geben.

Neue Programmiersprachen gehen da etwas andere Wege und `null`-Referenzierungen sind nicht möglich. In der Sprache Ruby zum Beispiel ist immer alles ein Objekt. Wo Java mit `null` ein „nicht belegt“ ausdrückt, macht das Ruby mit nil. Der feine Unterschied ist, dass nil ein Exemplar der Klasse NilClass ist, genau genommen ein Singleton, was es im System nur einmal gibt. nil hat auch ein paar öffentliche Methoden wie to\_s (wie Javas `toString()`), was dann einen leeren `String` liefert. Mit nil gibt es keine `NullPointerException` mehr, aber natürlich immer noch einen Fehler, wenn auf diesem Objekt vom Typ NilClass eine Methode aufgerufen wird, die es nicht gibt.

In Objective-C, der Standardsprache für iPhone-Programme, gibt es das Null-Objekt nil. Üblicherweise passiert nicht, wenn eine Nachricht an das nil-Objekt gesendet wird; die Nachricht wird einfach ignoriert.\[\[1\]\]() Es gibt Programmiersprachen, die noch etwas anders an das `null`-Problem herangehen. Bei der JVM-Sprache Scala gibt es für den Wert `null` einen eigenen Typ, nämlich Null. (Null erbt von AnyRef – was wiederum von Any erbt, dem absoluten Basistyp – und Null hat sogar mit Nothing einen Untertyp). Allerdings wird Scalas `null` nicht so wie Rubys `null` genutzt sondern entspricht Java `null`: Der Versuch, eine genullte Variable zu dereferenzieren, führt zu einer `NullPointerException`. Anders gesagt: Scala führt für `null` einen Typ ein, aber eine `NullPointerException` ist immer noch nicht passé. Statt aber in Scala `null` zurückzugeben, nutzen Programmierer etwas anderes: eine *Option*. Die Klasse Option repräsentiert optionale Werte und kommt in zwei Ausprägungen: `Some` und `None` (entspricht Rubys nil). Statt dass wie in Java eine Methoden eine Referenz direkt zurückgibt, geben Scala-Methoden etwas vom Typ Option zurück, und das heißt, entweder ein `None`- oder `Some`-Objekt. Das `Some`-Objekt ist ein Behälter und speichert die eigentliche Referenz. Eine Methode mit Option-Rückgabe sieht etwa so aus: if ( WertUngleichNull ) `Some`(Wert) else `None`. Mit dem parametrisierten Konstruktor `Some`(Wert) kommt der Wert in das `Some`-Objekt. Empfängt der Aufrufer die Rückgabe, kann er am Typ erkennen, ob die Operation erfolgreich war oder nicht. Das ist jedoch nicht, wie eine Option üblicherweise in Scala eingesetzt wird. Denn Option-Objekte (und somit `Some` oder `None`) besitzen eine Methode `getOrElse()`, sodass sich für eine Rückgabe result vom Typ Option schreiben lässt: `result.getOrElse(alternativerWert)`. Repräsentiert result ein `Some`-Objekt, so liefert die Implementierung von `getOrElse()` den gespeicherten Wert, ist es `None`, so liefert die Implementierung das Argument als Rückgabe. Spontan hört sich das jetzt noch nicht so wahnsinnig innovativ an, aber interessant wird die Option durch die Tatsache, dass Scala sie an verschiedenen Stellen intern in den Klassenbibliotheken einsetzt. Das liegt dran, dass die Option-Klasse an die 30 Methoden deklariert und viele der Methoden etwa bei Operationen auf Datenstrukturen aufgerufen werden. Wenn zum Beispiel auf allen Elementen der Liste eine Transformation durchgeführt werden soll, und ein `None`-Objekt befindet sich in der Liste, passiert beim Aufruf der Transformationsmethoden auf dem `None`-Objekt nichts, denn dort ist die Implementierung einfach leer.

---

\[\[1\]\]() Es gibt auch Compiler wie der GCC, der mit der Option -fno-nil-receivers dieses Verhalten abschaltet, um schnellere Maschinencode zu erzeugen. Denn letztendlich muss in Maschinencode immer ein Test stehen, der auf 0 prüft.

Kategorien: [Insel](https://www.tutego.de/blog/javainsel/category/insel/)

## 4 Kommentare

**Christian Ullenboom** · [03.08.2010 10:39](#comment-3415) · [Antwort auf einen Kommentar](#comment-3411)

In Java würde ich das nicht nachbilden, aber in Scala sitzt das so automatisch in den Bibliotheken.

**Christian Ullenboom** · [03.08.2010 10:37](#comment-3414) · [Antwort auf einen Kommentar](#comment-3412)

Ich habe das nicht geschrieben, weil an der Stelle im Buch dem Leser Generics noch nicht bekannt sind. Auf der anderen Seite ist das komplizierter Stuff, sodass ich den Kommentar verschieben werden.

**ANDI** · [01.08.2010 18:29](#comment-3412)

Irgendwie fehlen im obigen Beispielcode die Parametertypen der Klassen in spitzen Klammern. ```java interface Options<T> { ... } class Some<T> implements Options<T> { ... } class None<T> implements Options<T> { ... } ```

**andi** · [01.08.2010 18:25](#comment-3411)

Ist es denn jetzt sinnvoll ein Singleton-Null-Objekt zu haben im Gegensatz zu einem Java-"null"? Bzw. gibt es in der alltäglichen Programmierung einen Vorteil, wenn man beispielsweise `if(returnValue.equals(Nil.instance()))` anstatt `if(returnValue == null)` schreibt? Die Sache mit den Options klingt interessant, aber das könnte man ja auch in Java nachbauen. Beispielsweise mit einem parametrisierten Typ. Man müsste es eben nur konsequent einsetzen (die Collection-Klassen müssten wohl auch irgendwie nachgebildet werden...). ```java interface Options<T> { T getOrElse( T v ); } class Some<T> implements Options<T> { private T value; public Some( T theValue ) { this.value = theValue; } public T getOrElse( T v ) { return this.value; } } class None<T> implements Options<T> { public T getOrElse( T v ) { return v; } } ``` Hier aber auch wieder die Frage: Ist eine solche Vorgehensweise besser?

Die bisherigen Kommentare wurden aus WordPress übernommen. Neue Kommentare sind derzeit geschlossen.

[← Alle Beiträge](https://www.tutego.de/blog/javainsel/)

---

## Navigation

- Previous: [Java 7 Build 102](https://www.tutego.de/blog/javainsel/2010/07/java-7-build-102.md)
- Next: [2010 JVM Language Summit Wiki und Folien](https://www.tutego.de/blog/javainsel/2010/07/2010-jvm-language-summit-wiki-und-folien.md)
