Tại sao câu lệnh String switch không hỗ trợ trường hợp null?

Tôi chỉ tự hỏi tại sao switchcâu lệnh Java 7 không hỗ trợ một nulltrường hợp và thay vào đó ném NullPointerException? Xem dòng nhận xét bên dưới (ví dụ được lấy từ bài viết Hướng dẫn Java trênswitch ):

{
    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;
}

Điều này sẽ tránh được một ifđiều kiện để kiểm tra null trước mỗi lần switchsử dụng.

Như damryfbfnetsi chỉ ra trong các bình luận, JLS §14.11 có ghi chú sau:

Việc cấm sử dụng nulllàm nhãn chuyển đổi sẽ ngăn người ta viết mã không bao giờ được thực thi. Nếu switchbiểu thức là kiểu tham chiếu, nghĩa là Stringhoặc kiểu nguyên thủy được đóng hộp hoặc kiểu enum, thì lỗi thời gian chạy sẽ xảy ra nếu biểu thức ước lượng nullvào thời gian chạy. Theo đánh giá của các nhà thiết kế ngôn ngữ lập trình Java, đây là kết quả tốt hơn là âm thầm bỏ qua toàn bộ switchcâu lệnh hoặc chọn thực thi các câu lệnh (nếu có) sau defaultnhãn (nếu có).

(nhấn mạnh của tôi)

Trong khi câu cuối cùng bỏ qua khả năng sử dụng case null:, nó có vẻ hợp lý và đưa ra quan điểm về ý định của các nhà thiết kế ngôn ngữ.

Nếu chúng ta xem xét chi tiết triển khai, bài đăng trên blog này của Christian Hujer có một số suy đoán sâu sắc về lý do tại sao nullkhông được phép trong các công tắc (mặc dù nó tập trung vào công enumtắc thay vì công Stringtắc):

Trong phần mềm này, switchcâu lệnh thường sẽ biên dịch thành mã byte không cần thẻ. Và đối số "vật lý" switchcũng như các trường hợp của nó là ints. Giá trị int để bật được xác định bằng cách gọi phương thức Enum.ordinal(). Các lệnh [...] bắt đầu từ 0.

Điều đó có nghĩa, lập bản đồ nullđể 0sẽ không phải là một ý tưởng tốt. Một công tắc trên giá trị enum đầu tiên sẽ không thể phân biệt được với null. Có lẽ đó là một ý tưởng tốt để bắt đầu đếm số thứ tự cho enum ở mức 1. Tuy nhiên, nó không được định nghĩa như thế và định nghĩa này không thể thay đổi.

Trong khi các Stringcông tắc được triển khai khác nhau , thì enumcông tắc xuất hiện đầu tiên và đặt tiền lệ cho cách chuyển đổi trên loại tham chiếu nên hoạt động khi tham chiếu null.

Nói chung nulllà khó chịu để xử lý; có lẽ một ngôn ngữ tốt hơn có thể sống mà không có null.

Vấn đề của bạn có thể được giải quyết bằng

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

    }

Nó không đẹp, nhưng String.valueOf()cho phép bạn sử dụng Chuỗi null trong một công tắc. Nếu nó tìm thấy null, nó chuyển đổi nó thành "null", nếu không nó sẽ trả về cùng một Chuỗi mà bạn đã truyền nó. Nếu bạn không xử lý "null"rõ ràng, thì nó sẽ đi đến default. Nhắc nhở duy nhất là không có cách phân biệt giữa Chuỗi "null"và một nullbiến thực tế .

    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;

Đây là một nỗ lực để trả lời tại sao nó ném NullPointerException

Đầu ra của lệnh javap bên dưới cho thấy caseđược chọn dựa trên mã băm của switchchuỗi đối số và do đó ném NPE khi .hashCode()được gọi trên chuỗi null.

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

Điều này có nghĩa, dựa trên các câu trả lời cho hashCode của Java có thể tạo ra cùng một giá trị cho các chuỗi khác nhau không? , mặc dù hiếm, vẫn có khả năng hai trường hợp được khớp (hai chuỗi có cùng mã băm) Xem ví dụ này bên dưới

    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 mà

  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

Như bạn có thể thấy chỉ có một trường hợp được tạo cho "Ea"và "FB"với hai ifđiều kiện để kiểm tra sự trùng khớp với từng chuỗi trường hợp. Cách rất thú vị và phức tạp để thực hiện chức năng này!

Câu chuyện dài ... (và hy vọng đủ thú vị !!!)

Enum được giới thiệu lần đầu tiên trong Java1.5 ( tháng 9 năm2004 ) và lỗi yêu cầu cho phép chuyển đổi trên Chuỗi đã được gửi lại từ lâu ( tháng 10 năm 95 ). Nếu bạn xem bình luận được đăng trên lỗi đó vào tháng 6 năm2004 , có Don't hold your breath. Nothing resembling this is in our plans.vẻ như họ đã trì hoãn ( bỏ qua ) lỗi này và cuối cùng đã khởi chạy Java 1.5 trong cùng năm mà họ giới thiệu 'enum' với thứ tự bắt đầu từ 0 và quyết định ( bỏ lỡ ) không hỗ trợ null cho enum. Sau đó vào Java1.7 ( tháng 7 năm 2011 ) họ đã theo dõi ( bắt buộc) cùng một triết lý với String (tức là trong khi tạo mã byte, không có kiểm tra null nào được thực hiện trước khi gọi phương thức hashcode ()).

Vì vậy, tôi nghĩ rằng nó thực sự bắt đầu với thực tế enum xuất hiện đầu tiên và được triển khai với thứ tự bắt đầu từ 0 do họ không thể hỗ trợ giá trị null trong khối chuyển đổi và sau đó với String, họ đã quyết định ép buộc cùng một triết lý, ví dụ như giá trị null được phép trong khối chuyển đổi.

TL; DR Với String, họ có thể xử lý NPE (do cố gắng tạo mã băm cho null) trong khi thực hiện chuyển đổi mã java sang mã byte nhưng cuối cùng quyết định không.

Tham chiếu: TheBUG , JavaVersionHistory , JavaCodeToByteCode , SO

Theo Tài liệu Java:

Một switch hoạt động với các kiểu dữ liệu byte, short, char và int nguyên thủy. Nó cũng hoạt động với các kiểu liệt kê (được thảo luận trong Enum Type), lớp String và một vài lớp đặc biệt bao bọc một số kiểu nguyên thủy nhất định: Ký tự, Byte, Short và Integer (được thảo luận trong Số và Chuỗi).

Vì nullkhông có loại và không phải là một thể hiện của bất cứ thứ gì, nó sẽ không hoạt động với câu lệnh switch.

Câu trả lời đơn giản là nếu bạn sử dụng một công tắc có loại tham chiếu (chẳng hạn như loại nguyên thủy được đóng hộp), lỗi thời gian chạy sẽ xảy ra nếu biểu thức là null vì bỏ hộp thư sẽ ném NPE.

vì vậy trường hợp null (không hợp lệ) dù sao cũng không thể được thực thi;)

Tôi đồng ý với những nhận xét sâu sắc (Dưới mui xe ....) trong https://stackoverflow.com/a/18263594/1053496 trong câu trả lời của @Paul Bellora.

Tôi tìm thấy một lý do nữa từ kinh nghiệm của tôi.

Nếu 'case' có thể là null nghĩa là switch (biến) là null thì miễn là nhà phát triển cung cấp trường hợp 'null' phù hợp thì chúng ta có thể lập luận rằng nó ổn. Nhưng điều gì sẽ xảy ra nếu nhà phát triển không cung cấp bất kỳ trường hợp 'null' nào phù hợp. Sau đó, chúng ta phải khớp nó với trường hợp 'mặc định', đây có thể không phải là điều mà nhà phát triển dự định xử lý trong trường hợp mặc định. Do đó, việc khớp 'null' với mặc định có thể gây ra 'hành vi đáng ngạc nhiên'. Do đó, việc ném 'NPE' sẽ khiến nhà phát triển xử lý mọi trường hợp một cách rõ ràng. Tôi thấy ném NPE trong trường hợp này rất chu đáo.

Sử dụng lớp StringUtils của Apache

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