Là tốt hơn để sử dụng assert hoặc IllegalArgumentException cho các tham số phương thức cần thiết?

Trong Java, cái nào được khuyến khích cao hơn, và tại sao? Cả hai loại sẽ ném ngoại lệ, vì vậy về mặt xử lý chúng là như nhau. assertngắn hơn một chút, nhưng tôi không chắc vấn đề đó quan trọng đến mức nào.

public void doStuff(Object obj) {
    assert obj != null;
    ...
}

đấu với

public void doStuff(Object obj) {
    if (obj == null) {
        throw new IllegalArgumentException("object was null");
    }
    ...
}

HÃY THỬ!

Các xác nhận được loại bỏ trong thời gian chạy trừ khi bạn xác định rõ ràng là "bật các xác nhận" khi biên dịch mã của bạn. Các xác nhận Java không được sử dụng trên mã sản xuất và nên được giới hạn ở các phương thức riêng tư (xem Ngoại lệ so với Xác nhận ), vì các phương thức riêng tư dự kiến ​​chỉ được các nhà phát triển biết và sử dụng. Cũng assertsẽ ném AssertsError kéo dài Errorkhông Exception, và thông thường cho thấy bạn có một lỗi rất bất thường (như "OutOfMemoryError" rất khó để phục hồi, phải không?) Bạn không thể điều trị được.

Xóa cờ "bật xác nhận" và kiểm tra với trình gỡ lỗi và bạn sẽ thấy rằng bạn sẽ không thực hiện cuộc gọi ném IllegalArgumentException ... vì mã này chưa được biên dịch (một lần nữa, khi "e" bị xóa)

Tốt hơn là sử dụng cấu trúc thứ hai cho các phương thức công khai / được bảo vệ và nếu bạn muốn một cái gì đó được thực hiện trong một dòng mã, có ít nhất một cách mà tôi biết. Cá nhân tôi sử dụng Spring Framework 's Assertlớp mà có một vài phương pháp để kiểm tra đối số và ném 'IllegalArgumentException' trên thất bại. Về cơ bản, những gì bạn làm là:

Assert.notNull(obj, "object was null");

... Thực tế sẽ thực thi chính xác cùng mã mà bạn đã viết trong ví dụ thứ hai. Có một vài phương pháp hữu ích khác như hasText, hasLengthtrong đó.

Tôi không thích viết nhiều mã hơn mức cần thiết, vì vậy tôi rất vui khi giảm số dòng viết xuống 2 (2 dòng> 1 dòng) :-)

Bạn cần sử dụng một ngoại lệ. Sử dụng một xác nhận sẽ là sử dụng sai tính năng.

Các ngoại lệ không được kiểm tra được thiết kế để phát hiện lỗi lập trình của người dùng thư viện của bạn, trong khi các xác nhận được thiết kế để phát hiện lỗi trong logic của riêng bạn . Đây là những vấn đề riêng biệt không nên trộn lẫn.

Ví dụ: một khẳng định

assert myConnection.isConnected();

có nghĩa là "Tôi biết rằng mỗi đường dẫn mã dẫn đến xác nhận này đảm bảo myConnectionđược kết nối; nếu mã ở trên không có kết nối hợp lệ, thì nó sẽ ném ngoại lệ hoặc quay lại trước khi đạt đến điểm này."

Mặt khác, kiểm tra

if (!myConnection.isConnected()) {
    throw new IllegalArgumentException("connection is not established");
}

có nghĩa là "Gọi thư viện của tôi mà không thiết lập kết nối là lỗi lập trình".

Nếu bạn đang viết một hàm không cho phép nulllàm giá trị tham số hợp lệ, bạn nên thêm @Nonnullchú thích vào chữ ký và sử dụng Objects.requireNonNullđể kiểm tra xem đối số có nullvà ném NullPointerExceptionnếu nó là. Các @Nonnullchú thích là dành cho tài liệu và sẽ cung cấp những cảnh báo hữu ích tại thời gian biên dịch trong một số trường hợp. Nó không ngăn chặn nullđược thông qua tại thời gian chạy.

void doStuff(@Nonnull Object obj) {
    Objects.requireNonNull(obj, "obj must not be null");

    // do stuff...
}

Cập nhật: Các @Nonnullchú thích không phải là một phần của thư viện chuẩn Java. Thay vào đó, có rất nhiều tiêu chuẩn cạnh tranh từ các thư viện bên thứ ba (xem Tôi nên sử dụng chú thích Java nào @NotNull? ). Điều đó không có nghĩa là đó là một ý tưởng tồi để sử dụng nó, chỉ là nó không chuẩn.

Tôi luôn thích ném IllegalArgumentException hơn các xác nhận.

Các xác nhận được sử dụng chủ yếu trong JUnit hoặc các công cụ kiểm tra khác, để kiểm tra / xác nhận kết quả kiểm tra. Vì vậy, nó có thể mang lại ấn tượng sai cho các nhà phát triển khác rằng phương pháp của bạn là phương pháp thử nghiệm.

Ngoài ra, thật hợp lý khi ném IllegalArgumentException khi một phương thức đã được thông qua một đối số bất hợp pháp hoặc không phù hợp . Điều này phù hợp hơn với quy ước Xử lý ngoại lệ theo sau bởi các nhà phát triển Java.

IMO cái thứ hai tốt hơn một chút vì nó mang lại nhiều thông tin hơn và có thể được mở rộng hơn nữa (ví dụ: bằng cách mở rộng lớp ngoại lệ) để có nhiều thông tin hơn, nó cũng không sử dụng so sánh tiêu cực dễ hiểu hơn.

Tôi không sử dụng aserts rất nhiều, nhưng cách tiếp cận phổ biến với Barkock @NonNull: https://projectlombok.org/features/NonNull

Triển khai Lombok: nhập lombok.NonNull;

public class NonNullExample extends Something {
  private String name;

  public NonNullExample(@NonNull Person person) {
    super("Hello");
    this.name = person.getName();
  }
}

Phiên bản Java:

 import lombok.NonNull;

public class NonNullExample extends Something {
  private String name;

  public NonNullExample(@NonNull Person person) {
    super("Hello");
    if (person == null) {
      throw new NullPointerException("person");
    }
    this.name = person.getName();
  }
}

Lombok là thư viện thực sự khá đẹp mà tôi sử dụng ở mọi nơi