You could do a mix of both: give information useful for support (trace id, error code, etc) but don't explicitly say "send an email to support@bigcorp.com / call 01 23 45 67". The people on the tech side who are the CDN's clients will know who and how to call for support and if it's an end-user they'll be able to transmit this info. Bonus points for the tech guys to figure that there's an issue on their end and that they don't need to bother the CDN support.
I also agree with GP's point that extremely vague error messages are aggravating. Maybe I did something stupid / unexpected, and with a usable error message I'll be able to fix it on my own. Like sending the wrong file format, or whatever.
I absolutely hate when a system will just say "there's an error". And having cute animals or phrases doesn't change the fact that the error is useless. This is one of the reasons why I absolutely hate working with Windows. "An error occurred. Call your sysadmin". Right. I'm the sysadmin. What now?
This also trains users to never say what's wrong when they call for support. "Yeah, there's an issue with [thing]. What issue? It doesn't work. Oh, of course. There's only exactly one failure mode, so I'll get right on it."
I work in operations and get those fairly often even from people who should know better (software engineers and such) and I find it frustrating to no end that I always have to pull information from them even when there are clear error codes. So no, hiding this kind of info serves absolutely no purpose.
Well, the problem with the event viewer is that you kinda have to know what you're looking for beforehand.
I rarely use windows, so I don't know the conventions (if there are any), but I remember one case of someone attempting a remote desktop connection that had an error along the lines of what I said: "Cannot connect". I've never found where the logs for the RDP client were. For servers, we dump the logs in Elasticsearch, so a naïve query will at least set me on the right track.
I'm also not a particularly patient person, so the unbearable slowness of the event viewer's search function and the fact that I never know if I'm looking for Thing, Microsoft Thing, Windows Thing, or ThngSvc, I usually give up in frustration.
And, again, had I had an event id or something, the Find in the event viewer might have been more helpful.
I also agree with GP's point that extremely vague error messages are aggravating. Maybe I did something stupid / unexpected, and with a usable error message I'll be able to fix it on my own. Like sending the wrong file format, or whatever.
I absolutely hate when a system will just say "there's an error". And having cute animals or phrases doesn't change the fact that the error is useless. This is one of the reasons why I absolutely hate working with Windows. "An error occurred. Call your sysadmin". Right. I'm the sysadmin. What now?
This also trains users to never say what's wrong when they call for support. "Yeah, there's an issue with [thing]. What issue? It doesn't work. Oh, of course. There's only exactly one failure mode, so I'll get right on it."
I work in operations and get those fairly often even from people who should know better (software engineers and such) and I find it frustrating to no end that I always have to pull information from them even when there are clear error codes. So no, hiding this kind of info serves absolutely no purpose.