Spring Technology hints in RestTemplate exception message

This question seems inappropriate for SO. The nested exceptions message utility exposes Java type information:

I/O error on POST request for "http://localhost:8080/api/blahblah": Connection refused; nested exception is java.net.ConnectException: Connection refused

from, e.g.:

org.springframework.web.client.ResourceAccessException: I/O error on POST request for "http://localhost:8080/api/blahblah": Connection refused; nested exception is java.net.ConnectException: Connection refused
    at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:785)
    at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:711)
    at org.springframework.web.client.RestTemplate.postForObject(RestTemplate.java:437)

If the message was just:

I/O error on POST request for "http://localhost:8080/api/blahblah": Connection refused

this could be exposed to users without providing technology hints. The cause is captured with the stack-trace, so why expose the type information ("java.net.ConnectException") in the getMessage content?

The work-around is easy enough it just means duplicating the messaging which is probably okay; it certainly is in my case. But this seems like general issue that should be fixed in the framework but before I submit a PR with the broad test changes, is there any interest in this type of PR?

Comment From: SwingGuy1024

I always appreciate better error messages, and try to provide helpful details in the Exception messages in my own code.

Comment From: Nidhi-Tanwar14

My opinion is elaborate error messages helps debugging the issues faster

Comment From: snicoll

I wonder if the support of ProblemDetail would supersede this issue. What do you think @rstoyanchev?

Comment From: rstoyanchev

No I don't think RFC 7807 would change this since in this case it is a lower level IO exception.

It's coming from here. We are only printing of the message of the underlying exception, and its content is not in our control. I don't think it makes sense to exclude it entirely just because it might not be suitable for direct display to a user. Rather I would argue that exception messages should generally not be presented directly to users.