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 (e.g. 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.

I see nothing wrong with describing the error using the Message field. That's all the end user is going to really see... — Matthew Watson, Jul 04 '13 at 16:35
With some APIs, sometimes the only way to distinguish one unrelated error from the next is by parsing the message because they throw the same exception _type_ but with a different message. Surely, nobody here would _ever_ do that, right? — Chris Sinclair, Jul 04 '13 at 16:45

score 5 · Accepted Answer · answered Jul 04 '13 at 16:35

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.

The `Message` field could be optional for the client to provide if the exception type already gives you an indication of the type of error you've got, like e.g. with an `ArgumentNullException`. But it's not optional for the exception class author, who, as you mention, should always provide a "real" message there. — Jordão, Jul 04 '13 at 17:59

Jordão · Answer 2 · 2013-07-04T18:04:44.043

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.

score 1 · Answer 3 · edited May 23 '17 at 11:50

1

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

edited May 23 '17 at 11:50

Community

1
1

answered Jul 04 '13 at 16:40

score 1 · Answer 4 · answered Jul 04 '13 at 17:32

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

score 0 · Answer 5 · answered Jul 04 '13 at 16:39

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";
    }
}

score 0 · Answer 6 · answered Jul 04 '13 at 17:32

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

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

6 Answers6