Is it a good practice not to use Message field of an Exception class in C#?

Question

According to this article , use the Message field of an Exception class is not a good programming practice.

However, when I try to throw an exception (eg ArgumentException ) in my project, how can I add my custom exception information? Should I use Exception.Data Property?

Instead of using:

throw new ArgumentException("My Custom Info.");

Should I use:

ArgumentException ex = new ArgumentException();
ex.Data["CustomInfo"] = "My Custom Info.";
throw ex;

The code becomes cumbersome, if I don't use Message field.

Is it a good practice not to use Message field of an Exception class?

Thanks in advance.

Answer 1

I actually would suggest that the Message field is critical. You should always have a "real" message in your Message field.

The issue is more with trying to put data into the message itself. If you need custom data to be passed along with your exception, then making a custom Exception class, with the data as properties, is a better practice. This doesn't mean you shouldn't have a Message - your custom exception, and any exception for that matter, should have a clear message describing what went wrong, but any additional data sent as a payload should be handled via a custom Exception class.

Answer 2

If you need custom information to be part of the exception, it's generally advisable to create your own exception class where you'll create separate properties to structure the information.

For your example, the relevant exception constructor could look like this:

public CustomException(string message, string customInfo) : base(message) {
  CustomInfo = customInfo;
}

The customInfo parameter would populate a read-only property in the class:

public string CustomInfo { get; private set; }

Use it like this:

throw new CustomException("My message", "My Custom Info.");

Note also that the article you linked mentions that the exception message is not a good place to store structured information , because that will force clients to parse it to obtain relevant bits, since you'd have to format all the info into a single string.

Answer 3

Custom exceptions are the way to go. Check out the following links.

What are industry standard best practices for implementing custom exceptions in C#?

http://msdn.microsoft.com/en-us/library/vstudio/ms229064%28v=vs.100%29.aspx

Answer 4

It would be helpful to read the solution that Microsoft recommends to developers.

http://msdn.microsoft.com/en-us/library/seyhszts.aspx

If you are interested in enterprise level Exception Handling, "The Exception Handling Application Block" would be best solution.

http://msdn.microsoft.com/en-us/library/dn169621.aspx

Answer 5

You can create your own exception by this way:

public class MyException : Exception
{
    public MyException() : base("The text you want")
    {
        // you can add here helpLink, Hresult and etc.
        this.HelpLink = "http://whateverurl";
    }
}

Answer 6

The mentioned article:

Exceptions are classes. When you return the exception information, create fields to store data. If you fail on doing it, people will need to parse the Message field to get the information they need. Now, think what will happen to the calling code if you need to localize or even just correct a spelling error in error messages. You may never know how much code you'll break by doing it.

That's silly. Exceptions are exceptions and nothing that you analyze to be able to rescue the situation. Exceptions should never be part of the normal application flow. Hence it doesn't matter where you put the diagnostics information.

I always use the Message to provide information. It's the easiest approach and works with ToString() which is the #1 away to print exception details.

I've written a series about exception handling here: http://blog.gauffin.org/2013/04/what-is-exceptions/#.UdWxqflplc4