Warum unterstützt die String switch-Anweisung keinen Nullfall?

Ich frage mich nur, warum die Java 7- switchAnweisung keinen nullFall unterstützt und stattdessen wirft NullPointerException. Siehe die kommentierte Zeile unten (Beispiel aus dem Artikel über Java-Tutorialsswitch ):

{
    String month = null;
    switch (month) {
        case "january":
            monthNumber = 1;
            break;
        case "february":
            monthNumber = 2;
            break;
        case "march":
            monthNumber = 3;
            break;
        //case null:
        default: 
            monthNumber = 0;
            break;
    }

    return monthNumber;
}

Dies hätte eine ifBedingung für eine Nullprüfung vor jeder switchVerwendung vermieden .

Wie damryfbfnetsi weist darauf hin , in den Kommentaren, JLS §14.11 hat die folgende Anmerkung:

Das Verbot der Verwendung nullals Switch-Label verhindert, dass Code geschrieben wird, der niemals ausgeführt werden kann. Wenn es sich bei dem switchAusdruck um einen Referenztyp handelt, Stringdh um einen primitiven Typ mit Box oder einen Aufzählungstyp, tritt ein Laufzeitfehler auf, wenn der Ausdruck zur nullLaufzeit ausgewertet wird. Nach switchAnsicht der Entwickler der Java-Programmiersprache ist dies ein besseres Ergebnis, als die gesamte Anweisung stillschweigend zu überspringen oder die Anweisungen (falls vorhanden) nach dem defaultLabel (falls vorhanden) auszuführen .

(Hervorhebung von mir)

Während der letzte Satz die Möglichkeit der Verwendung überspringt case null:, erscheint er vernünftig und bietet einen Einblick in die Absichten der Sprachdesigner.

Wenn wir uns eher die Implementierungsdetails ansehen, enthält dieser Blog-Beitrag von Christian Hujer einige aufschlussreiche Spekulationen darüber, warum nullSwitches nicht zulässig sind (obwohl er sich enumeher auf den Switch als auf den StringSwitch konzentriert):

Unter der Haube wird die switchAnweisung normalerweise zu einem Tablesswitch-Bytecode kompiliert. Und das "physikalische" Argument switchsowie seine Fälle sind ints. Der einzuschaltende int-Wert wird durch Aufrufen der Methode bestimmt Enum.ordinal(). Die [...] Ordnungszahlen beginnen bei Null.

Das heißt, Mapping nullauf 0wäre keine gute Idee. Ein Einschalten des ersten Enum-Werts wäre von Null nicht zu unterscheiden. Vielleicht wäre es eine gute Idee gewesen, die Ordnungszahlen für Aufzählungen bei 1 zu zählen. Es wurde jedoch nicht so definiert, und diese Definition kann nicht geändert werden.

Während StringSwitches unterschiedlich implementiert sind , stand der enumSwitch an erster Stelle und legte den Präzedenzfall für das Verhalten eines Referenztyps fest, wenn sich die Referenz befindet null.

Im Allgemeinen nullist es böse zu handhaben; Vielleicht kann eine bessere Sprache ohne leben null.

Ihr Problem könnte durch gelöst werden

    switch(month==null?"":month)
    {
        ...
        //case "":
        default: 
            monthNumber = 0;

    }

Es ist nicht schön, aber String.valueOf()Sie können einen Null-String in einem Switch verwenden. Wenn es findet null, konvertiert es es in "null", andernfalls gibt es nur den gleichen String zurück, den Sie übergeben haben. Wenn Sie nicht "null"explizit behandeln, wird es zu gehen default. Die einzige Einschränkung ist, dass es keine Möglichkeit gibt, zwischen dem String "null"und einer tatsächlichen nullVariablen zu unterscheiden.

    String month = null;
    switch (String.valueOf(month)) {
        case "january":
            monthNumber = 1;
            break;
        case "february":
            monthNumber = 2;
            break;
        case "march":
            monthNumber = 3;
            break;
        case "null":
            monthNumber = -1;
            break;
        default: 
            monthNumber = 0;
            break;
    }
    return monthNumber;

Dies ist ein Versuch zu beantworten, warum es wirft NullPointerException

Die Ausgabe des folgenden javap-Befehls zeigt, dass caseer basierend auf dem Hashcode der switchArgumentzeichenfolge ausgewählt wurde und daher NPE auslöst, wenn er .hashCode()für eine Nullzeichenfolge aufgerufen wird.

6: invokevirtual #18                 // Method java/lang/String.hashCode:()I
9: lookupswitch  { // 3
    -1826660246: 44
     -263893086: 56
      103666243: 68
        default: 95
   }

Dies bedeutet, basierend auf den Antworten auf Kann Javas HashCode denselben Wert für verschiedene Zeichenfolgen erzeugen? Obwohl selten, besteht immer noch die Möglichkeit, dass zwei Fälle übereinstimmen (zwei Zeichenfolgen mit demselben Hashcode). Siehe dieses Beispiel unten

    int monthNumber;
    String month = args[0];

    switch (month) {
    case "Ea":
        monthNumber = 1;
        break;
    case "FB":
        monthNumber = 2;
        break;
    // case null:
    default:
        monthNumber = 0;
        break;
    }
    System.out.println(monthNumber);

Javap für welche

  10: lookupswitch  { // 1
              2236: 28
           default: 59
      }
  28: aload_3       
  29: ldc           #22                 // String Ea
  31: invokevirtual #24                 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
  34: ifne          49
  37: aload_3       
  38: ldc           #28                 // String FB
  40: invokevirtual #24                 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
  43: ifne          54
  46: goto          59 //Default

Wie Sie sehen können, wird nur ein Fall für "Ea"und "FB"mit zwei ifBedingungen generiert , um eine Übereinstimmung mit jeder Fallzeichenfolge zu überprüfen. Sehr interessante und komplizierte Art der Implementierung dieser Funktionalität!

Lange Rede, kurzer Sinn ... (und hoffentlich interessant genug !!!)

Enum wurde erstmals in Java1.5 ( September 2004 ) eingeführt, und der Fehler , der das Einschalten des Strings zuließ, wurde vor langer Zeit ( Oktober 1995 ) abgelegt . Wenn Sie sich den Kommentar ansehen, der zu diesem Fehler im Juni 2004 veröffentlicht wurde , heißt es, dass Don't hold your breath. Nothing resembling this is in our plans.sie diesen Fehler zurückgestellt ( ignoriert ) und schließlich Java 1.5 im selben Jahr gestartet haben, in dem sie 'enum' mit Ordnungszahl ab 0 eingeführt und entschieden haben ( verpasst ), um null für enum nicht zu unterstützen. Später in Java1.7 ( Jul'2011 ) folgten sie ( gezwungen) die gleiche Philosophie wie bei String (dh beim Generieren des Bytecodes wurde vor dem Aufruf der Methode hashcode () keine Nullprüfung durchgeführt).

Ich denke, es läuft darauf hinaus, dass die Aufzählung zuerst einging und mit dem ordinalen Start bei 0 implementiert wurde, aufgrund dessen sie den Nullwert im Schalterblock nicht unterstützen konnten, und später mit String beschlossen sie, dieselbe Philosophie zu erzwingen, dh den Nullwert nicht im Schalterblock erlaubt.

TL; DR Mit String hätten sie sich um NPE kümmern können (verursacht durch den Versuch, Hashcode für null zu generieren), während sie die Konvertierung von Java-Code in Byte-Code implementierten, sich aber schließlich dagegen entschieden.

Ref: TheBUG , JavaVersionHistory , JavaCodeToByteCode , SO

Laut Java Docs:

Ein Switch arbeitet mit den primitiven Datentypen Byte, Short, Char und Int. Es funktioniert auch mit Aufzählungstypen (siehe Aufzählungstypen), der String-Klasse und einigen speziellen Klassen, die bestimmte primitive Typen umschließen: Zeichen, Byte, Kurz und Ganzzahl (siehe Zahlen und Zeichenfolgen).

Da nulles keinen Typ hat und keine Instanz von irgendetwas ist, funktioniert es nicht mit einer switch-Anweisung.

Die Antwort lautet einfach: Wenn Sie einen Switch mit einem Referenztyp (z. B. einem primitiven Typ mit Box) verwenden, tritt der Laufzeitfehler auf, wenn der Ausdruck null ist, da durch das Entpacken die NPE ausgelöst wird.

Fall null (was illegal ist) könnte also sowieso nie ausgeführt werden;)

Ich stimme aufschlussreichen Kommentaren (unter der Haube ...) in https://stackoverflow.com/a/18263594/1053496 in der Antwort von @Paul Bellora zu.

Ich habe aus meiner Erfahrung einen weiteren Grund gefunden.

Wenn 'case' null sein kann, was bedeutet, dass switch (variable) null ist, können wir argumentieren, dass es in Ordnung ist, solange der Entwickler einen passenden 'null'-Fall bereitstellt. Was passiert jedoch, wenn der Entwickler keinen passenden Nullfall bereitstellt? Dann müssen wir es einem 'Standard'-Fall zuordnen, der möglicherweise nicht das ist, was der Entwickler im Standardfall beabsichtigt hat. Daher kann das Anpassen von 'null' an einen Standardwert 'überraschendes Verhalten' verursachen. Wenn Sie also 'NPE' auslösen, kann der Entwickler alle Fälle explizit behandeln. Ich fand das Werfen von NPE in diesem Fall sehr nachdenklich.

Verwenden Sie die Apache StringUtils-Klasse

String month = null;
switch (StringUtils.trimToEmpty(month)) {
    case "xyz":
        monthNumber=1;  
    break;
    default:
       monthNumber=0;
    break;
}