Đang tích cực ném AssertionError trong thực hành tốt Java?

Question

Nhìn qua Joshua Bloch Java hiệu quả - Second Edition ', tôi stumbled khi các mã sau vào trang 152:

double apply(double x, double y) { 
    switch(this) { 
     case PLUS: return x + y; 
     case MINUS: return x - y; 
     case TIMES: return x * y; 
     case DIVIDE: return x/y; 
    } 
    throw new AssertionError("Unknown op: " + this); 
} 

Bây giờ những gì confuses me là, rằng AssertionError đang tích cực ném. Đó có phải là thực hành tốt không? Để xác nhận sự hiểu biết của tôi được sử dụng để không can thiệp vào mã như vậy khi lập trình java được khởi động mà không có xác nhận được bật và do đó các câu lệnh khẳng định không được thực thi, hành vi không thay đổi. Tôi sẽ khá bối rối, nếu tôi nhận được AssertionException khi tôi chạy một chương trình mà thậm chí không bật xác nhận.

Mặc dù tôi hiểu rằng trường hợp mẫu có thể xảy ra khá thường xuyên, bạn phân tích một vài tùy chọn khác nhau và nếu không có tùy chọn nào khác, bạn nên ném ngoại lệ.

Vì vậy, thực hành tốt là ném một số AssertionException vào đây, hoặc tốt hơn là nên ném một cái khác? Nếu vậy, cái nào sẽ phù hợp nhất? Có lẽ IllegalArgumentException?

---

Chỉnh sửa để làm rõ: Câu hỏi của tôi không phải là về việc liệu chúng ta nên ném một Error ở đây, nhưng nếu chúng ta muốn ném một Exception hoặc một Error, cái nào nó nên được? Và thực tiễn tốt là chủ động ném AssertionError s? Tài liệu nói rằng Được cho là đã xác nhận rằng một xác nhận đã thất bại, vì vậy tôi có cảm giác rằng chúng ta không nên chủ động ném nó. Đúng không?

---

Second Chỉnh sửa: Xóa câu hỏi: Liệu nó tốt thực hành để chủ động ném một AssertionError, hoặc là nên tránh, mặc dù nó có thể? (Tôi đoán đọc tài liệu là sau)

Answer 1

Tôi đồng ý với ông Bloch ở đây - các lựa chọn thay thế (IllegalArgumentException, IllegalStateException và UnsupportedOperationException) không truyền đạt đúng mức độ nghiêm trọng của vấn đề và người gọi có thể cố gắng nắm bắt và xử lý trường hợp này một cách sai lầm. Trên thực tế, nếu dòng này bao giờ đạt đến chương trình được đề cập là bị hỏng và điều duy nhất cần làm là thoát. Điểm này ở đây là enum có một tập hợp các giá trị hữu hạn, do đó không thể đạt được dòng throw - nó sẽ chỉ xảy ra nếu định nghĩa của enum đã thay đổi mà không cần sửa phương thức thể hiện này. Ném một RuntimeException cho thấy người gọi đã thực hiện một sai lầm, khi trong thực tế, phương pháp (và enum) chính nó bị hỏng. Nâng cao rõ ràng một AssertionError chỉ ra một cách chính xác các bất biến mà phương pháp này mong đợi đã bị vi phạm.

Ổi có bài viết hữu ích chia nhỏ when to raise different types of exceptions. Họ viết:

A conventional assertion is a check that should only fail if the class itself (that contains the check) is broken in some way. (In some cases this can extend to the package.) These can take various forms including postconditions, class invariants, and internal preconditions (on non-public methods).

An impossible-condition check is one that cannot possibly fail unless surrounding code is later modified, or our deepest assumptions about platform behavior are grossly violated. These should be unnecessary but are often forced because the compiler can't recognize that a statement is unreachable, or because we know something about the control flow that the compiler cannot deduce.

Trang này cho biết cách xử lý các trường hợp này là AssertionError. Các nhận xét trong lớp học Verify của họ cũng cung cấp một số thông tin chi tiết hữu ích về việc chọn ngoại lệ. Trong trường hợp AssertionError có vẻ quá mạnh, hãy tăng VerifyException có thể là một sự thỏa hiệp tốt.

Đối với các câu hỏi cụ thể của Error hoặc RuntimeException, nó không thực sự quan trọng (cả hai đều không được kiểm soát và do đó có khả năng sẽ tiếp tục hành trình cuộc gọi stack mà không bị bắt), nhưng người gọi có nhiều khả năng để cố gắng phục hồi từ một RuntimeException . Việc bẻ khóa ứng dụng trong một trường hợp như thế này là một tính năng , bởi vì nếu không chúng tôi sẽ tiếp tục chạy một ứng dụng (vào thời điểm này) không chính xác. Nó chắc chắn ít có khả năng người gọi sẽ nắm bắt và xử lý AssertionError (hoặc Error hoặc Throwable), nhưng tất nhiên người gọi có thể làm bất cứ điều gì họ muốn.

Answer 2

Theo ý kiến ​​của tôi, AssertionError sẽ không chính xác để sử dụng tại đây.

From the docs, một AssertionError mở rộng lớp cơ sở Error

An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch.

lỗi nên gây tử vong, trong khi tôi mong chờ chương trình của bạn để xử lý này, và hiển thị cho người dùng một thông điệp cảnh báo về hoạt động chưa biết.

Nếu có gì ở đây, tôi mong đợi một số UnsupportedOperationException sẽ được ném và xử lý ở nơi khác trong ngăn xếp cuộc gọi.

Thrown to indicate that the requested operation is not supported.

xem xét, trường hợp không trong một máy tính, nhưng bất kỳ dòng mã có sử dụng enums:

Nếu một nhà phát triển đã thêm một giá trị mới cho một enum hiện có, tôi không mong chờ chức năng mà làm cho sử dụng enum hiện tại này để gọi một lỗi, chỉ vì giá trị mới không được hỗ trợ.

Answer 3

Tôi nghĩ cả AssertionError hoặc IllegalAE đều không tốt ở đây. Lỗi xác nhận không tốt như được chỉ ra trong câu trả lời của Matt. Và các đối số không sai ở đây, những đối số đó chỉ được truyền cho một phương thức sai hoạt động this. Vì vậy, IAE có thể không tốt. Tất nhiên đây là câu hỏi và câu trả lời dựa trên ý kiến.

Ngoài ra, tôi không chắc chắn cho phép xác nhận là bắt buộc đối với việc ném AssertionError hoặc một assertionError có nghĩa là các xác nhận đã được bật.

Answer 4

Như tôi đã hiểu, phương pháp của bạn là phương pháp của đối tượng enum. Trong hầu hết các trường hợp khi ai đó thêm giá trị enum mới, anh ta cũng nên sửa đổi phương thức "áp dụng". Bạn nên ném UnsupportedOperationException trong trường hợp này.

Answer 5

lỗi Về, các Java Tutorial trạng thái:

The second kind of exception is the error. These are exceptional conditions that are external to the application, and that the application usually cannot anticipate or recover from.

Ngoài ra, Programming With Assertions dẫn trạng thái:

Do not use assertions for argument checking in public methods.

Vì vậy, tôi nghĩ rằng ngoại lệ là đúng cách để kiểm tra cho các loại hình trường hợp.

Tôi khuyên bạn nên sử dụng new UnsupportedOperationException("Operator " + name() + " is not supported."); vì nó mô tả tốt hơn vấn đề theo ý kiến ​​của tôi (tức là nhà phát triển đã thêm giá trị enum nhưng quên triển khai yêu cầu).

Tuy nhiên tôi nghĩ rằng trường hợp mẫu này nên sử dụng một mô hình AbstractEnum thiết kế thay vì một công tắc:

PLUS { 
    double apply(double x, double y) { 
     return x + y; 
    } 
}, 
MINUS { 
    double apply(double x, double y) { 
     return x - y; 
    } 
}, 
TIMES { 
    double apply(double x, double y) { 
     return x * y; 
    } 
}, 
DIVIDE { 
    double apply(double x, double y) { 
     return x/y; 
    } 
}; 

abstract double apply(double x, double y); 

Đó là ít bị lỗi từ mã này sẽ không biên dịch cho đến khi tất cả các trường hợp thực hiện apply.

Answer 6

Tôi muốn

double apply(double x, double y) { 
    switch(this) { 
     case PLUS: return x + y; 
     case MINUS: return x - y; 
     case TIMES: return x * y; 
     default: assert this==DIVIDE: return x/y; 
    } 
} 

1. Chúng ta không nên ném AssertionError vì nó chỉ nên dành cho khẳng định thực tế.
2. Khác với các xác nhận và một số khối catch không được có một mã duy nhất không thể thực hiện được.

Nhưng tôi nhất muốn https://stackoverflow.com/a/41324246/348975