Should the Exception.Message property be shown directly to users? [closed]

That may sound like a silly question but I’d like to gather some input regarding this. I’m used to see 2 flavors of handling exception messages. First there is the simple pattern where you show the Message directly to the user:

try
{
    service.Update();
}
catch (Exception ex)
{
    ShowMessage(ex.Message);
}

The alternative way of treating exceptions is to consider strongly-typed exceptions to mean something that is then interpreted by the ‘controller’ class (or whatever piece of code than handles pushing information to the user):

try
{
    service.Update();
}
catch (NetworkException ex)
{
    ShowMessage("Network is unavailable.");
}
catch (Exception ex)
{
    ShowMessage("Something went wrong with the update.");
}

The first approach requires that every message used by exceptions (whether passed in the constructor by the calling code or managed inside a strongly-typed exception) be ‘user-ready’ (clean, properly formulated and localized, etc.). The second approach transfers this responsibility to the controller code. Plus it might require having very specific strongly-typed exceptions to make sure that every catch block is able to interpret them correctly.

So to whom is aimed the Message property of the Exception class (in C#, Java…)? The end-user or the programmer?

Thank you,

Answer

No, I feel that exception details (Message and StackTrace) are best left to logs at best. Often times the exception text is too technical for display to the user and may actually give a malicious user information that could be used to hack or otherwise attack the system.

Thus, i would pick appropriate verbiage for different exceptions that is meaningful but not the actual technical details.

Of course, if this is a technical tool aimed at a particular technical audience, that may change things (like a database tool such as Toad may choose to show details of Oracle exceptions, etc). But in general, I would avoid it.