Quy tắc chung về việc tạo một ngoại lệ trong Java là gì?

Question

Tôi đã ở trong cả hai tình huống:

• Tạo quá nhiều ngoại lệ tùy chỉnh
• Sử dụng quá nhiều chung lớp ngoại lệ

Trong cả hai trường hợp dự án bắt đầu OK nhưng nhanh chóng trở thành một nguyên cần thiết để duy trì (và refactor).

Vậy thực tiễn tốt nhất về việc tạo ra các lớp Ngoại lệ của riêng bạn là gì?

Answer 1

The Java Specialists đã viết một bài về Exceptions in Java, và trong đó họ liệt kê một vài "thực hành tốt nhất" để tạo ra ngoại lệ, tóm tắt dưới đây:

• Đừng Viết Exceptions riêng (có rất nhiều ngoại lệ hữu ích mà đã là một phần của Java API)

• viết Exceptions hữu ích (nếu bạn phải viết Exceptions của riêng bạn, chắc chắn rằng họ cung cấp thông tin hữu ích về vấn đề này xảy ra)

Answer 2

Về cơ bản, mỗi công việc đều xứng đáng có ngoại lệ riêng. Khi bạn bắt ngoại lệ, bạn không phân biệt các trường hợp khác nhau, như bạn thường làm với các đối tượng, do đó bạn cần các kiểu con khác nhau. Sử dụng quá nhiều ngoại lệ tùy chỉnh là trường hợp tôi thấy hầu như không xảy ra.

Một lời khuyên là tạo ngoại lệ nếu cần và nếu rõ ràng là một loại ngoại lệ trùng lặp với loại ngoại lệ khác, hãy tái cấu trúc mã bằng cách hợp nhất hai. Tất nhiên nó sẽ giúp nếu một số suy nghĩ đi vào cấu trúc ngoại lệ ngay từ đầu. Nhưng nói chung, hãy sử dụng ngoại lệ tùy chỉnh cho tất cả các trường hợp không tương ứng 1: 1 với các trường hợp ngoại lệ hiện tại, theo tình huống cụ thể.

Mặt khác, NullPointerException s và IndexOutofBoundsException có thể thực sự thường phù hợp. Tuy nhiên, đừng bắt những cái này (ngoại trừ việc đăng nhập) vì chúng là lỗi lập trình có nghĩa là sau khi ném chúng, chương trình ở trạng thái không xác định.

Answer 3

Quy tắc chung của tôi là khi khách hàng (người gọi) có thể hợp lý muốn làm điều gì đó khác, tùy thuộc vào loại ngoại lệ được ném, các loại ngoại lệ bổ sung được bảo hành. Thường xuyên hơn không, tuy nhiên, các loại ngoại lệ thêm là không cần thiết. Ví dụ: nếu người gọi đang viết mã như

try { 
    doIt(); 
} catch (ExceptionType1 ex1) { 
    // do something useful 
} catch (ExceptionType2 ex2) { 
    // do the exact same useful thing that was done in the block above 
} 

thì rõ ràng là các loại ngoại lệ bổ sung là không cần thiết. Tất cả các quá thường xuyên tôi thấy (hoặc buộc phải viết) mã như thế này bởi vì mã được gọi là quá hăng hái trong việc tạo ra các loại ngoại lệ mới.

Answer 4

Nếu tôi không thể tìm thấy một ngoại lệ có tên mô tả loại lỗi nào được gây ra thì tôi tự tạo.

Đó là quy tắc-ngón tay cái của tôi.

Answer 5

quy tắc riêng của ngón tay cái:

tôi không bao giờ ném ngoại lệ, ngoại trừ trong các thử nghiệm đơn vị khi những gì bạn ném là không thích hợp và theres không có lý do để chi tiêu thêm bất cứ lúc nào trên đó.

Tôi tạo loại ngoại lệ tùy chỉnh của riêng mình cho các lỗi xảy ra trong logic nghiệp vụ tùy chỉnh của tôi. Loại ngoại lệ này được sử dụng càng nhiều càng tốt để tính lại các ngoại lệ khác, ngoại trừ trong trường hợp khách hàng có khả năng hiển thị những gì thực sự xảy ra.

Answer 6

Đừng làm những gì các nhà phát triển tại công ty của tôi đã làm. Ai đó đã tạo ra một [sic] InvalidArguementException song song với java.lang.IllegalArgumentException, và bây giờ chúng ta sử dụng nó trong (nghĩa đen) hàng trăm lớp. Cả hai chỉ ra rằng một phương pháp đã được thông qua một đối số bất hợp pháp hoặc không phù hợp. Nói về một sự lãng phí ...

Joshua Bloch diện này trong Java hiệu quả Hướng dẫn Lập trình Ngôn ngữ [kinh thánh của tôi về khu du lịch đầu tiên trên Best Practices] Chương 8. Trường hợp ngoại lệmục 42: Favor việc sử dụng các ngoại lệ chuẩn . Dưới đây là một chút về những gì anh ấy nói,

Việc sử dụng lại các ngoại lệ có sẵn có một số lợi ích. Đứng đầu trong số này, nó làm cho API của bạn dễ dàng hơn để tìm hiểu và sử dụng vì nó phù hợp với các quy ước đã được thiết lập mà các lập trình viên đã quen thuộc với [sự nhấn mạnh của tôi, chứ không phải là] của Bloch. Thứ hai là các chương trình sử dụng API của bạn dễ đọc hơn vì chúng không bị lộn xộn với các ngoại lệ không quen thuộc. Cuối cùng, ít hơn các lớp ngoại lệ có nghĩa là một dấu chân bộ nhớ nhỏ hơn và ít thời gian hơn để nạp các lớp.

Ngoại lệ phổ biến nhất được sử dụng lại là IllegalArgumentException. Đây thường là ngoại lệ để ném khi người gọi vượt qua trong một đối số có giá trị không phù hợp. Ví dụ, điều này sẽ là ngoại lệ để ném nếu người gọi đã thông qua một số âm trong một tham số đại diện cho số lần một số hành động được lặp lại.

Điều đó nói rằng, bạn nên không bao giờ ném Ngoại lệ. Java có một loạt các trường hợp ngoại lệ tích hợp được lựa chọn tốt, đa dạng và được nhắm mục tiêu tốt bao gồm hầu hết các tình huống AND mô tả ngoại lệ đã xảy ra đủ tốt để bạn có thể khắc phục nguyên nhân.

Thân thiện với những người lập trình phải duy trì mã của bạn trong tương lai.

Answer 7

Trong khi tạo ngoại lệ của riêng bạn:

• Tất cả các trường hợp ngoại lệ phải là con của Throwable Class

• Nếu bạn muốn viết một ngoại lệ kiểm tra cũng được thực thi bởi Handle hoặc Khai Rule, bạn cần phải mở rộng Exception Class

• Nếu bạn muốn viết thực thi thời gian chạy, bạn cần mở rộng Lớp ngoại lệ thời gian chạy.