Adding extra information to a custom exception

Question

I've created a custom exception for a very specific problem that can go wrong. I receive data from another system, and I raise the exception if it bombs while trying to parse that data. In my custom exception, I added a field called "ResponseData", so I can track exactly what my code couldn't handle.

In custom exceptions such as this one, should that extra response data go into the exception "message"? If it goes there, the message could be huge. I kind of want it there because I'm using Elmah, and that's how I can get at that data.

So the question is either: - How can I get Elmah to record extra information from a field in a custom exception OR - Should extra exception details go into the "message" property?

Answer 1

I don't understand the question -- you're extending System.Exception, and you already added the Elmah field. That's where it belongs -- as a public property of the exception itself.

Answer 2

This is elmah: elmah

Answer 3

You shouldn't fill .Message with debug information, but rather with a concise, helpful piece of text.

http://msdn.microsoft.com/en-us/library/system.exception.message.aspx

The text of Message should completely describe the error and should, when possible, explain how to correct it. The value of the Message property is included in the information returned by ToString.

The Message property is set only when creating an Exception. If no message was supplied to the constructor for the current instance, the system supplies a default message that is formatted using the current system culture.

[..]

Notes to Inheritors:

The Message property is overridden in classes that require control over message content or format. Application code typically accesses this property when it needs to display information about an exception that has been caught.

The error message should be localized.

Response data does not qualify as a description.

Not being familiar with elmah, I can't tell you how to extend the Exception class while using it. Does elmah implement its own subclass to Exception? Or an interface? Can you subclass it yourself?

Answer 4

I don't fully understand the question but you seem to be asking what to do with additional exception data, if that is not your question feel free to ignore this.

I think an important question to ask is what exactly is the exception message for? It is not for knowing where the exception came from, the stack trace is for that; it is not to encapsulate an exception in a more general one, that should be done with the InnerException field; in the case where your exception is only raised from a particular place in your code it isn't even for describing what kind of error you had - thats what the type of the exception is for.

Generally I use the message field to provide simple, human-readable tips that a programmer that is not me, seeing this error for the first time can use to gain an understanding of the underlying system. I consider the message field to be appropriate for a short (one sentence) explanation, a hint as to how this error is frequently raised, or a reference to further reading.

So, as far as I understand your question, I think that the best way to store this 'additional information' that is received from another system is as an InnerException. I don't know Elmah, but if it's worth its salt it will check for InnerExceptions and store them.

Answer 5

Elmah is a http module that records unhandled exceptions.

I guess it's just a limitation of Elmah, since it doesn't store custom fields. I guess I'll have to ask those guys. I have the extra field in there for the response data, but Elmah does not store it.

Answer 6

In custom exceptions such as this one, should that extra response data go into the exception "message"?

No, as Sören already pointed out. However, your exception type could override ToString and sensibly add the response data information there. This is a perfectly normal practice followed by many of the exception types in the BCL (Base Class Library) so you will not find yourself swimming against the tide. For example, have a look at the System.IO.FileNotFoundException.ToString implementation in SSCLI (Rotor):

public override String ToString()
{
    String s = GetType().FullName + ": " + Message;

    if (_fileName != null && _fileName.Length != 0)
        s += Environment.NewLine + String.Format(Environment.GetResourceString("IO.FileName_Name"), _fileName);

    if (InnerException != null)
        s = s + " ---> " + InnerException.ToString();

    if (StackTrace != null)
        s += Environment.NewLine + StackTrace;

    try
    {
        if(FusionLog!=null)
        {
            if (s==null)
                s=" ";
            s+=Environment.NewLine;
            s+=Environment.NewLine;
            s+="Fusion log follows: ";
            s+=Environment.NewLine;
            s+=FusionLog;
        }
    }
    catch(SecurityException)
    {

    }
    return s;
}

As you can see, it appends the content of FusionLog property, which represent extra information in case of assembly load failures.

How can I get Elmah to record extra information from a field in a custom exception

ELMAH stores the result of calling ToString on an exception as the details of the error so if you have ToString implemented as prescribed, the information would get logged without further work. The only issue is that the logged detail will be unstructured text.

Answer 7

The Exception class contains a dictionary (named Data, I believe) that you can use to associate custom data with a vanilla exception.