Tại sao có một dự án RuntimeException cụ thể?

Question

Có bất kỳ điểm nào trong việc có com.myco.myproj.MyProjRuntimeException, mà completley mở rộng RuntimeException không?

Answer 1

Có. Làm ném bỏ chọn ngoại lệ và phân lớp chúng.

Có nhiều cuộc trò chuyện về việc liệu ngoại lệ đã kiểm tra có thực sự tốt hay không. Tóm lại, nếu tôi ném một ngoại lệ đã kiểm tra, liệu khách hàng của tôi có thực sự có liên quan gì đến nó không?

Trường hợp ngoại lệ không được kiểm tra là cách tốt để thông báo cho khách hàng của bạn về các tình huống đặc biệt (bao gồm tiền điều kiện bất hợp pháp) và chưa gây phiền toái cho họ khi có nhu cầu kết nối cuộc gọi đến API của bạn với các khối try-catch, phần lớn thời gian về cơ bản không phục vụ mục đích gì ngoài việc gỡ lỗi, truy tìm, v.v.

Vậy tại sao không ném RuntimeException? Nó không phải là thanh lịch và nó là ít có thể đọc được. Làm cho nó ngoại lệ của riêng bạn mà xuất phát từ nó, ngay cả khi nó không có lý do khác hơn là cụ thể hơn khi ném ngoại lệ.

Answer 2

Không thực sự. Các thông tin bổ sung bạn nhận được từ việc có tên ngoại lệ hiển thị trong một dấu vết ngăn xếp có thể được đưa ra bằng cách chỉ cần thiết lập chuỗi thông báo của một tiêu chuẩn RuntimeException. Tuy nhiên (hãy nghĩ về nó), nó có thể hữu ích để phân lớp RuntimeException chỉ đơn giản là để thêm một chuỗi tùy chỉnh vào bất kỳ thư nào.

Tôi có xu hướng chỉ thực hiện các ngoại lệ được kiểm tra tùy chỉnh; nói chung, các ngoại lệ tiêu chuẩn không được kiểm tra bao gồm đủ các trường hợp tiềm năng rồi.

Answer 3

Đó là một phong cách tốt để duy trì phân cấp ngoại lệ của riêng bạn.

Nhưng tôi đã thấy chỉ một vài người có thể sử dụng kỹ thuật này với lợi nhuận thực sự.

Answer 4

trong Java hiệu quả, Joshua Bloch viết: ngoại lệ

Sử dụng thời gian chạy để chỉ lỗi lập trình. Đại đa số ngoại lệ thời gian chạy cho biết vi phạm điều kiện tiên quyết.

Điều đó đang được nói, bạn có thể sử dụng ngoại lệ thời gian chạy đó làm lớp cơ sở cho một hệ thống phân cấp ngoại lệ thời gian chạy, được sử dụng trong dự án của bạn. Bằng cách đó, lỗi trở nên rõ ràng hơn và có thể theo dõi được.

Answer 5

Tùy thuộc vào việc bạn có muốn xử lý tình trạng ngoại lệ khác với các ngoại lệ khác ở xa hơn ngăn xếp cuộc gọi hay không. Nếu bạn định bắt và xử lý ngoại lệ, thì tôi khuyên bạn nên tạo loại tùy chỉnh. Nó làm cho mã dễ đọc hơn và các điều khoản bắt sạch hơn. Nếu bạn không bắt được ngoại lệ, thì có lẽ ít lý do để tạo một loại mới.

Answer 6

Nhiều người (tôi và nhà thiết kế của C# được bao gồm) believe ngoại lệ đã kiểm tra là một thử nghiệm ngôn ngữ không thành công và tránh chúng. Sau đó, tạo ra hệ thống phân cấp ngoại lệ của riêng bạn dưới RuntimeException là một bước rõ ràng.

Answer 7

Rod Jonhson đã viết về điều này trong thiết kế và phát triển J2EE từng người một và như trong câu trả lời của Tom RuntimeException nên được sử dụng cho các lỗi lập trình. Một ví dụ tốt là SQLException, API truy cập dữ liệu cấp thấp hơn nên bắt chúng và ném "SQLRuntimeException" của riêng bạn vì phần lớn thời gian mã gọi không thể làm bất kỳ điều gì với ngoại lệ. Bằng cách này, apis cấp cao hơn của bạn không bắt buộc phải nắm bắt hoặc mang ngoại lệ cấp thấp hơn trong chữ ký của họ, làm cho mã đơn giản hơn và tập trung hơn vào miền doanh nghiệp.

Answer 8

ngoại lệ Subclass dựa trên cách thức chúng được xử lý chứ không phải là người đã viết chúng ...

Thông thường thời gian chạy ngoại lệ có thể không được xử lý theo cách khác so với đăng nhập lỗi và có thể hiển thị một thông báo lỗi.

ngoại lệ Kiểm tra khả năng có thể có một dự phòng cụ thể, và trong trường hợp đó họ nên probly không phân lớp một "MyFrameWorkException" - như trong trường hợp đó, bắt một MyFrameWorkException sẽ không làm nhiều hơn là đánh bắt chung (đăng nhập, vv)

Thực tiễn khá tồi tệ là phát minh ra toàn bộ các trường hợp ngoại lệ có ít điểm chung, ngoại trừ thực tế là chúng thuộc về một khuôn khổ cụ thể. (gói được cho là sử dụng cho việc đó.)

Nó là hoàn toàn ok để phân lớp RuntimeException (nếu lớp con hiện không phải là một sự phù hợp thần)

Document trường hợp ngoại lệ không được kiểm soát. Hãy thận trọng với các ngoại lệ đã kiểm tra và không xây dựng hệ thống phân cấp.

Answer 9

Theo ý kiến ​​của tôi, bạn chỉ nên tạo Ngoại lệ mới nếu bạn thực sự cần đến chúng, nghĩa là muốn bắt chúng và thực hiện điều trị cụ thể cho chúng. Trên tất cả các trường hợp khác, tôi không thực sự thấy tính hữu dụng.