Bắt một số ngoại lệ và sửa lại một ngoại lệ chung

Question

Tôi đang sử dụng phản chiếu để thêm một số dữ liệu vào biến riêng tư bên trong lớp học từ thư viện của bên thứ ba. Trên đường đi có khoảng bốn ngoại lệ khác nhau có thể được ném; tất cả chúng đều liên quan đến sự phản chiếu, và tất cả chúng đều không xảy ra. Tôi đang hardcoding tên của lớp và biến có liên quan. Tôi không nhận được bất kỳ lớp học không tìm thấy hoặc lĩnh vực không tìm thấy lỗi, trừ khi thư viện được nâng cấp một ngày và đã thay đổi đáng kể.

Tôi không muốn khai báo tất cả bốn ngoại lệ này cho người gọi để xử lý. Anh ấy có khả năng không bao giờ nhìn thấy chúng. Tôi muốn bắt tất cả những điều này và ném một ngoại lệ khác để nói "Đã xảy ra lỗi phản chiếu Java; có khả năng thư viện đã được nâng cấp và thay đổi theo cách không tương thích với phương pháp này". Có một ngoại lệ Java tiêu chuẩn tôi có thể ném mà chỉ là một lỗi phản ánh chung? Tôi có nên định nghĩa của riêng mình không? Hoặc nó sẽ là tốt nhất để chỉ tuyên bố rằng phương pháp này có thể ném tất cả các ngoại lệ phản xạ có thể?

Answer 1

Bạn có thể biến tất cả Ngoại lệ thành AssertionError nếu bạn không bao giờ mong đợi chúng xảy ra. InvocationTargetException có thể được unwrapped nếu bạn muốn đối phó với một ngoại lệ cụ thể. Nếu bạn muốn ném ngoại lệ thực tế ném theo phương pháp chứ không phải là InvocationTargetException bạn có thể sử dụng thủ thuật này, nhưng nó có thể gây lộn xộn hơn hữu ích

} catch (InvocationTargetException e) { 
    // Throw any exception in the current thread (even if it is a checked exception) 
    Thread.currentThread().stop(e.getCause()); 
} 

Answer 2

Tôi thường tự hỏi mình những câu hỏi sau:

• thể bất cứ ai mà các cuộc gọi phương pháp này xử lý các loại ngoại lệ khác nhau khác nhau không?
• ... Hoặc họ có đối xử với họ như nhau không?
• Người gọi/người dùng có thể khôi phục được từ lỗi này không?

Nếu mã gọi có khả năng xử lý tất cả bốn trường hợp ngoại lệ này giống nhau (như lỗi không thể khôi phục), thì sẽ rất hợp lý để nắm bắt từng trường hợp và ném lại ngoại lệ chung chung (đơn). Nếu bạn làm như vậy, hãy đảm bảo bạn đính kèm ngoại lệ đã tạo dưới dạng ngoại lệ bên trong, chỉ để giúp gỡ lỗi hoặc khắc phục sự cố ở đầu bên kia.

Answer 3

Có một số tranh cãi về các ngoại lệ được kiểm tra và bỏ chọn. Cá nhân tôi nghĩ rằng ngoại lệ kiểm tra là ý tưởng tồi tệ nhất trong Java - nhưng đó chỉ là một ý kiến ​​(tuy nhiên tôi không đơn độc nghĩ rằng)

Dù sao, tôi nghĩ điều quan trọng là thay đổi chúng thành một ngoại lệ không được kiểm tra . Thường xuyên hơn tôi không sử dụng một duy nhất như IllegalStateException hoặc IllegalParameterException - với một mô tả văn bản rõ ràng, hai ngoại lệ đó bao gồm 90% của crap có thể đi sai với một phương thức.

Answer 4

Tôi không nghĩ rằng việc khai báo ngoại lệ trong trường hợp này là hợp lý. Vì vậy, tôi sẽ bắt các ngoại lệ từ sự phản chiếu, có thể đăng nhập một dấu vết ngăn xếp, và ném một số RuntimeException, có lợi thế là nó không cần phải được khai báo. Bạn chỉ có thể sử dụng RuntimeException với một thông điệp phù hợp, nếu bạn lười.

Answer 5

Trước hết, không sử dụng sự phản chiếu trừ khi bạn thực sự, thực sự phải, bởi vì nó là điều ác. Giả sử bạn phải:

Vì bạn đang mã hóa tất cả các tên, chỉ cần rời khỏi Method.invoke, Constructor.newInstance và Field.get/set. Tôi muốn đề nghị chỉ cần rethrowing các trường hợp ngoại lệ kiểm tra, bạn có thể đối phó với gói trong Error. Họ không nên xảy ra, và nếu bạn muốn đối phó với nó, tôi đề nghị làm kiểm tra tại lớp intialisation thời gian. InvocationTargetException nên, tất nhiên, được unwrapped và xử lý một cách thích hợp (ném một gói Error cho ngoại lệ kiểm tra mà phương pháp/constructor đã không tuyên bố).

Answer 6

Làm thế nào về việc có những lớp ngoại lệ kéo dài từ một GeneralException và bắt mà rằng GeneralException?

Tôi sẽ thử ngay bây giờ! :)