Code Styling

Your code is very good at first look. Good structure, code-styling, new features used, clever trics.

Functionality and Usability

The message is for the user, the code is for you to debug it. Exceptions currently allow adding good message and naming properties won't help a bit (to the user, if it is designed to tell the usere: "You did something wrong" like "Wrong Value Format"), but to diagnose problems, you'll need more than property/method name. And for that, you have the stack trace.

To state it simple: the problem is not in the exception and what additional info it can carry (it already has the stack-trace), but in the way you present it. This is my own code I use:

public static string GetLongMessage(this Exception ex)
{
    StringBuilder sb = new StringBuilder();
    while(ex != null)
    {
        sb.AppendLine(ex.Message).AppendLine();
        sb.AppendLine(ex.StackTrace).AppendLine().AppendLine();
        ex = ex.InnerException;
    }
    return sb.ToString();
}

Code Styling

Your code is very good at first look. Good structure, code-styling, new features used, clever trics.

Functionality and Usability

The message is for the user, the code is for you to debug it. Exceptions currently allow adding good message and naming properties won't help a bit (to the user, if it is designed to tell the user: "You did something wrong" like "Wrong Value Format"), but to diagnose problems, you'll need more than property/method name. And for that, you have the stack trace.

To state it simple: the problem is not in the exception and what additional info it can carry (it already has the stack-trace), but in the way you present it. This is my own code I use:

public static string GetLongMessage(this Exception ex)
{
    StringBuilder sb = new StringBuilder();
    while(ex != null)
    {
        sb.AppendLine(ex.Message).AppendLine();
        sb.AppendLine(ex.StackTrace).AppendLine().AppendLine();
        ex = ex.InnerException;
    }
    return sb.ToString();
}

Example (added)

I have purposedly created bad XML file and opened it in my app. The result is not so perfect (for a user, because they should never hand-edit the XML), but I can clearly see the problem:

You can see, what is wrong, in the title - File Open Error And can track the exceptions to see what elements and what attribute is wrong (page-state-badattr). It won't tell much to the user (except for the title - could not properly parse selected file), but I know, immediatelly. Actually, the stack trace is not that important here, but the exception chain is perfect!

But to achieve this, I had to create custom exceptions and add additional data (element/attribute name) to them. But that should be normal :)