JAX-RS khách hàng: xử lý ResponseProcessingException

Question

Một số phương pháp yêu cầu gọi quá tải, chẳng hạn như: get() và post(Entity<?> entity) (có những người khác) của SyncInvoker trở lại một đối tượng Response, chứ không phải là nội dung unmarshalled.

tôi nhận thấy rằng trong trường hợp của get(), không có tài liệu ResponseProcessingException, trong khi các phương pháp khác, chẳng hạn như tất cả 3 quá tải post phương pháp, có thể ném một ResponseProcessingException.

Tôi biết rằng ResponseProcessingException là một RuntimeException mà kế thừa từ ProcessingException, nhưng tôi vẫn sẽ giải thích điều này có nghĩa rằng phương pháp get() sẽ không ném một ResponseProcessingException.

Điều này có đúng không? Điều gì về ClientResponseFilter? Tại sao hành vi khác với hành vi của các phương thức yêu cầu cuộc gọi khác (put, post, ..)?

Ngoài ra, Javadoc cho các phương pháp mà làm ném một ResponseProcessingException nói:

trong trường hợp xử lý của một HTTP response nhận thất bại (ví dụ như trong một bộ lọc hoặc trong quá trình chuyển đổi dữ liệu đối tượng đáp ứng với một ví dụ về một loại Java cụ thể là ).

Phần:

hoặc trong quá trình chuyển đổi dữ liệu đối tượng đáp ứng với một thể hiện của một loại đặc biệt Java

có vẻ là sai ở đây, như là phương pháp readEntity không nên chưa được gọi là:

https://jersey.java.net/documentation/latest/filters-and-interceptors.html#d0e9915

Đây có phải là bản sao & dán lỗi tài liệu không?

Tôi đoán bộ lọc sẽ là trường hợp hợp lệ.

Answer 1

Tài liệu chắc chắn không phù hợp. Rõ ràng là ResponseProcessingException được dự định sẽ bị ném khi một lỗi ClientResponseFilter không thành công.

Việc thực hiện tôi đang nhìn (RESTEasy 3.0.16) thực hiện điều này:

try { 
    filter.filter(requestContext, responseContext); 
} catch (ResponseProcessingException e) { 
    throw e; 
} catch (Throwable e) { 
    throw new ResponseProcessingException(response, e); 
} 

Không có lý do rằng phương pháp get sẽ không khai báo ngoại lệ khi put và post phương pháp làm. Nội bộ chúng đều được xử lý bởi cùng một mã.

Kết luận của tôi là sự khác biệt nhỏ về tài liệu giữa các phương pháp chỉ là sự giám sát.

Điều thú vị là, trong bản sao của tôi về mã nguồn, phương pháp get() có dòng này trong javadoc của nó:

/** 
* @throws javax.ws.rs.ProcessingException 
*   in case the invocation processing has failed. 

Trong khi tất cả các phương pháp tương tự khác (ví dụ get(Class<T>)) đều được ghi nhận như sau:

/** 
* @throws ProcessingException   in case the request processing or subsequent I/O operation fails. 

Điều gì khiến mắt tôi là tên lớp học đầy đủ trong tên đầu tiên. Chỉ là một linh cảm, nhưng điều đó khiến tôi nghĩ rằng nó được đặt vào một thời điểm khác hoặc bởi một người khác. Có lẽ tôi đang overanalysing. Tôi đã cố gắng nhìn vào lịch sử sửa đổi, nhưng tất cả những gì tôi thấy là một cam kết duy nhất nói "di chuyển mã nguồn đến kho lưu trữ của chính nó"). Quá nhiều cho điều đó.

Tuy nhiên, như bạn đã chỉ ra, đó không phải là lỗi, vì ResponseProcessingException và là một phân lớp của ProcessingException và thậm chí không phải là ngoại lệ được kiểm tra.

Answer 2

Nếu bạn không muốn ngoại lệ của mình được bao bọc trong ResponseProcessingException, bạn có thể làm cho ngoại lệ của bạn mở rộng nó, sau đó nó sẽ đến mà không cần gói. Tất nhiên, điều này là khả thi chỉ khi bạn sử dụng ngoại lệ của riêng bạn và bạn đang OK với RuntimeException.