I am going to echo the sentiment of a lot of other comments here, but, while well-intentioned, trying to interpret errors and present them in a "user friendly"

I am going to echo the sentiment of a lot of other comments here, but, while well-intentioned, trying to interpret errors and present them in a "user friendly" format is extremely situation dependent. As an example, I had delivered an internal application for a client that interfaced with a third-party system that was also deployed internally and maintained by the client's technical staff. My application was primarily used by other, non-technical staff. Occationally, my application would get an error message from the other system and we would report an error with content like, "A problem occurred with <other server> while trying to <action>. Please report to <technical staff>. Error: <insert error message>". The problem is that the non-technical staff complained that the error message was "too hard to understand" and my PM initially asked me to, essentially, reinterpret the errors from the third-party server to make them more understandable. I pointed out that the errors in the third party system were not documented, had no error code attached to them, and would put us in the position of perpetual maintainance as the long-tail of previously-unseen errors poped up over time. Not to mention the fact that error messages could radically change as the third-party server was updated over time. Fortunately, my argument was convincing and we avoided stepping into an unbounded tar pit of uncompensated development time, all in the name of making things "easier" for the end user.