I like the rationale behind the accepted answer, but I must respectfully disagree at least with my interpretation of limiting the information to what is "actionable". I want to know just a little teeny bit more than that as a user than "unexpected error".
And admittedly I am a bit computer-savvy and I have that bias, but I don't think this is a particularly biased view. Because I can try my best to remove that bias by applying this mindset to domains for which I have little expertise, like aviation.
While I know little about aviation, say my flight is delayed or canceled and the only thing the staff tell me is, "We had an unexpected error. Please wait 3 hours for a subsequent flight." You'll at least find me a bit more of a disgruntled customer in those cases because, even though it doesn't really affect my course of action either way, I just want to know just a tiny bit more about why I'm being inconvenienced this way as a paying customer.
If they just said like, "We're experiencing turbulent weather," or "We had a medical emergency in our previous flight," or an equipment malfunction or whatever, that's plenty enough for me to sympathize much more than "unexpected error" and be a little more content sitting around and waiting 3 hours for the next flight. Actually I might even prefer some technobabble that goes over my head to "unexpected error" like, "All right, the words coming out of your mouth are going into my ear but not reaching the central processor. But I get now that there's some sort of issue there and I'ma go grab some coffee and sit over there! Hope you guys get that issue sorted out with that thingamajig!"
And often in terms of exception-handling, I think you usually have enough of that kind of basic info of what happened at the catch
site, even if you want to hide the more technical details of the exception, like:
try
{
load_file(file_name);
}
catch (const exception& ex)
{
exception_dialog("Failed to load file: '{1}'.", file_name);
}
And that's not even displaying what might potentially be the very technical information attached to the exception, but it's at least telling us considerably more than "unexpected error". It at least provides a contextual "what/where/when" even if it doesn't say "why/how". I think at least the desire for this basic level of info is not particularly biased by my computer-savviness.
The rest is probably very specific to your customers and particular needs. But my appeal is at least for something just a teeny bit more than "unexpected error".