Làm cách nào để sử dụng chú thích @Nullable và @Nonnull hiệu quả hơn?

Tôi có thể thấy rằng @Nullablevà @Nonnullcác chú thích có thể hữu ích trong việc ngăn chặn NullPointerExceptions nhưng chúng không lan truyền rất xa.

• Hiệu quả của các chú thích này giảm hoàn toàn sau một cấp độ gián tiếp, vì vậy nếu bạn chỉ thêm một vài chú thích thì chúng không lan truyền rất xa.
• Vì các chú thích này không được thi hành tốt, nên có nguy cơ giả sử giá trị được đánh dấu @Nonnulllà không rỗng và do đó không thực hiện kiểm tra null.

Mã dưới đây gây ra một tham số được đánh dấu @Nonnulllà nullkhông có bất kỳ khiếu nại nào. Nó ném một NullPointerExceptionkhi nó được chạy.

public class Clazz {
    public static void main(String[] args){
        Clazz clazz = new Clazz();

        // this line raises a complaint with the IDE (IntelliJ 11)
        clazz.directPathToA(null);

        // this line does not
        clazz.indirectPathToA(null); 
    }

    public void indirectPathToA(Integer y){
        directPathToA(y);
    }

    public void directPathToA(@Nonnull Integer x){
        x.toString(); // do stuff to x        
    }
}

Có cách nào để làm cho các chú thích này được thực thi nghiêm ngặt hơn và / hoặc tuyên truyền hơn nữa không?

Câu trả lời ngắn: Tôi đoán những chú thích này chỉ hữu ích cho IDE của bạn để cảnh báo bạn về các lỗi con trỏ null.

Như đã nói trong cuốn sách "Clean Code", bạn nên kiểm tra các tham số của phương thức công khai của mình và cũng tránh kiểm tra các bất biến.

Một mẹo hay khác là không bao giờ trả về giá trị null, nhưng sử dụng Null Object Pattern thay thế.

Khác với IDE của bạn cung cấp cho bạn các gợi ý khi bạn chuyển nullsang các phương thức dự kiến ​​đối số sẽ không có giá trị, còn có các ưu điểm khác:

• Các công cụ phân tích mã tĩnh có thể kiểm tra giống như IDE của bạn (ví dụ FindBugs)
• Bạn có thể sử dụng AOP để kiểm tra các xác nhận này

Điều này có thể giúp mã của bạn dễ bảo trì hơn (vì bạn không cần nullkiểm tra) và ít bị lỗi hơn.

Tôi nghĩ rằng câu hỏi ban đầu này gián tiếp chỉ ra một khuyến nghị chung rằng kiểm tra con trỏ null thời gian chạy vẫn cần thiết, mặc dù @NonNull được sử dụng. Tham khảo liên kết sau:

Chú thích loại mới của Java 8

Trong blog trên, chúng tôi khuyên bạn nên:

Chú thích loại tùy chọn không thể thay thế cho xác thực thời gian chạy Trước khi chú thích loại, vị trí chính để mô tả những thứ như nullable hoặc phạm vi là trong javadoc. Với các chú thích Loại, giao tiếp này đi vào mã byte theo cách để xác minh thời gian biên dịch. Mã của bạn vẫn nên thực hiện xác nhận thời gian chạy.

Biên dịch ví dụ ban đầu trong Eclipse ở mức tuân thủ 1.8 và với phân tích null dựa trên chú thích được bật, chúng tôi nhận được cảnh báo này:

    directPathToA(y);
                  ^
Null type safety (type annotations): The expression of type 'Integer' needs unchecked conversion to conform to '@NonNull Integer'

Cảnh báo này được diễn đạt tương tự như những cảnh báo bạn nhận được khi trộn mã được tạo ra với mã kế thừa bằng cách sử dụng các loại thô ("chuyển đổi không được kiểm tra"). Chúng ta có cùng một tình huống ở đây: phương thức indirectPathToA()có chữ ký "di sản" ở chỗ nó không chỉ định bất kỳ hợp đồng null nào. Các công cụ có thể dễ dàng báo cáo điều này, vì vậy chúng sẽ đuổi bạn xuống tất cả các con hẻm nơi chú thích null cần được truyền bá nhưng chưa được.

Và khi sử dụng một cách thông minh @NonNullByDefault chúng ta thậm chí không cần phải nói điều này mỗi lần.

Nói cách khác: việc chú thích null có "tuyên truyền rất xa" hay không có thể phụ thuộc vào công cụ bạn sử dụng và mức độ nghiêm trọng của bạn đối với tất cả các cảnh báo do công cụ đưa ra. Với các chú thích null TYPE_USE, cuối cùng bạn cũng có tùy chọn để cho phép công cụ cảnh báo bạn về mọi NPE có thể có trong chương trình của bạn, bởi vì null đã trở thành một thuộc tính phức tạp của hệ thống loại.

Tôi đồng ý rằng các chú thích "không truyền bá rất xa". Tuy nhiên, tôi thấy lỗi ở phía lập trình viên.

Tôi hiểu Nonnullchú thích là tài liệu. Phương thức sau đây biểu thị yêu cầu (như một điều kiện tiên quyết) một đối số không null x.

    public void directPathToA(@Nonnull Integer x){
        x.toString(); // do stuff to x        
    }

Đoạn mã sau đây có lỗi. Phương thức gọi directPathToA()mà không thực thi đó ylà không null (nghĩa là nó không đảm bảo điều kiện tiên quyết của phương thức được gọi). Một khả năng là thêm một Nonnullchú thích vào indirectPathToA()(tuyên truyền điều kiện tiên quyết). Khả năng hai là kiểm tra tính vô hiệu của yin indirectPathToA()và tránh cuộc gọi đến directPathToA()khi nào ylà null.

    public void indirectPathToA(Integer y){
        directPathToA(y);
    }

Những gì tôi làm trong các dự án của mình là kích hoạt tùy chọn sau trong kiểm tra mã "Điều kiện và ngoại lệ không đổi":
Đề xuất chú thích @Nullable cho các phương thức có thể trả về null và báo cáo các giá trị nullable được truyền cho các tham số không chú thích

Khi được kích hoạt, tất cả các tham số không chú thích sẽ được coi là không null và do đó bạn cũng sẽ thấy cảnh báo về cuộc gọi gián tiếp của mình:

clazz.indirectPathToA(null); 

Để kiểm tra mạnh mẽ hơn, Khung kiểm tra có thể là một lựa chọn tốt (xem hướng dẫn hay này .
Lưu ý : Tôi chưa sử dụng và có thể có vấn đề với trình biên dịch Jack: xem lỗi này

Trong Java, tôi sẽ sử dụng loại Tùy chọn của Guava . Là một loại thực tế bạn có được trình biên dịch đảm bảo về việc sử dụng nó. Thật dễ dàng để bỏ qua nó và có được một NullPointerException, nhưng ít nhất chữ ký của phương thức truyền đạt rõ ràng những gì nó mong đợi như là một đối số hoặc những gì nó có thể trả về.

Nếu bạn sử dụng Kotlin, nó hỗ trợ các chú thích nullable này trong trình biên dịch của nó và sẽ ngăn bạn chuyển null sang phương thức java yêu cầu đối số không null. Sự kiện mặc dù câu hỏi này ban đầu được nhắm mục tiêu tại Java, tôi đề cập đến tính năng Kotlin này vì nó được nhắm mục tiêu cụ thể vào các chú thích Java này và câu hỏi là "Có cách nào để làm cho các chú thích này được thi hành nghiêm ngặt hơn và / hoặc tuyên truyền hơn nữa không?" và tính năng này làm cho các chú thích này được thực thi nghiêm ngặt hơn .

Lớp Java sử dụng @NotNullchú thích

public class MyJavaClazz {
    public void foo(@NotNull String myString) {
        // will result in an NPE if myString is null
        myString.hashCode();
    }
}

Lớp Kotlin gọi lớp Java và truyền null cho đối số được chú thích bằng @NotNull

class MyKotlinClazz {
    fun foo() {
        MyJavaClazz().foo(null)
    }
}  

Lỗi trình biên dịch Kotlin thi hành @NotNullchú thích.

Error:(5, 27) Kotlin: Null can not be a value of a non-null type String

xem: http://kotlinlang.org/docs/reference/java-interop.html#nullability-annotations

Vì tính năng mới của Java 8 Tùy chọn, bạn không nên sử dụng @Nullable hoặc @Notnull trong mã của riêng bạn nữa . Lấy ví dụ dưới đây:

public void printValue(@Nullable myValue) {
    if (myValue != null) {
        System.out.print(myValue);
    } else {
        System.out.print("I dont have a value");
}

Nó có thể được viết lại bằng:

public void printValue(Optional<String> myValue) {
    if (myValue.ifPresent) {
        System.out.print(myValue.get());
    } else {
        System.out.print("I dont have a value");
}

Sử dụng một tùy chọn buộc bạn phải kiểm tra giá trị null . Trong đoạn mã trên, bạn chỉ có thể truy cập giá trị bằng cách gọiget phương thức.

Một ưu điểm khác là mã có thể dễ đọc hơn . Với việc bổ sung Java 9 ifPftimeOrElse , hàm thậm chí có thể được viết là:

public void printValue(Optional<String> myValue) {
    myValue.ifPresentOrElse(
        v -> System.out.print(v),
        () -> System.out.print("I dont have a value"),
    )
}