[jira] [Commented] (CXF-7119) ResponseExceptionMapper not used for technical exceptions (e.g. IOException)

["Sergey Beryozkin (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CXF-7119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15633453#comment-15633453 ] 

Sergey Beryozkin commented on CXF-7119:
---------------------------------------

It is not a bug and works as designed. ResponseExceptionMapper produces a typed Throwable from a given HTTP response which is not even available in this case.
What I can do is to update AbstractClient to return ProcessingException with the Fault's cause, so in the client code you'd work with the standard exception classes: catch ProcessingException and work with IOException, etc 

> ResponseExceptionMapper not used for technical exceptions (e.g. IOException)
> ----------------------------------------------------------------------------
>
>                 Key: CXF-7119
>                 URL: https://issues.apache.org/jira/browse/CXF-7119
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 3.1.3
>            Reporter: Jörg Hohwiller
>
> When using CXF for REST/JAX-RS service clients I quickly noticed that I need to tweak the error handling. My services use an ExceptionMapper that provides error details via JSON result payload. Hence I want to access this and render an exception with further details and more context information what works fine with ResponseExceptionMapper. 
> However, when a technical error (IOException such as unkown host, connection refused, timeout, etc.) occurrs I only get generic errors from CXF client (org.apache.cxf.interceptor.Fault: Could not send Message.). This is undesired but unfortunately my custom ResponseExceptionMapper is never called for such technical errors. There seems to be no way to archive my goal with CXF itself. I could only wrap the client again with a custom written dynamic proxy to reach my goal.
> It seems that CXF hardwires this behaviour:
> https://github.com/apache/cxf/blob/master/rt/rs/client/src/main/java/org/apache/cxf/jaxrs/client/AbstractClient.java#L596
> https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/interceptor/MessageSenderInterceptor.java#L64
> It would be awesome if in such case ResponseExceptionMapper would also be applied so I have the chance to interfere and produce better exceptions (e.g. with a message containing the name of the application/microservice that could not be called, the URL, etc.) for my individual needs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)