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.