Which .Net 2.0 Exception should I throw in this circumstance?

Question

Hi there,

I'm writing yet another ActiveRecord implementation for a company that is less scared of my code than they are the designation "Release Candidate" on CastleProject's implementation. Anyway, I'm using Attributes on each property in the base class to map them to the returning DataSet's columns:

[ResultColumnAttribute("CUST_FIRST_NAME")]
public string FirstName
        {
            get { return _columnName; }
            set { _columnName = value; }
        }

so that when I instantiate the class from a DataSet, I assign that property value the column's value. What exception should I throw when a column is mapped with an attribute, but doesn't show up in the DataSet? I don't want to go and write a custom one (lazy), and I think Application.Exception is a little nondescript.

Answer 1

This exception is localized to your domain and as such I think you would be better off writing your own InvalidMappingException.

Here is how I would write it:

[Serializable]
public class InvalidMappingException : Exception
{
    public InvalidMappingException() { }

    public InvalidMappingException(String message)
     : base(message) { }

    public InvalidMappingException
        (String message, Exception innerException)
         : base(message, innerException) { }

    protected InvalidMappingException
        (SerializationInfo info, StreamingContext context)
         : base(info, context) { }
}

Answer 2

First off, Castle Windsor is now officially version 2, no release candidate :)

I think there is only a limited set of Exceptions within the .NET framework you can really throw from your code:

• NotImplementedException
• InvalidOperationException
• ArgumentException
• ArgumentNullException

there may be more, I am hoping for other posts. If none of them fits you should write your own. With the "exc" code snippet in Visual Studio, lazyness is not really an argument.

Answer 3

I would write a custom exception, specific to your implementation. This is a very specific, customized situation, and a custom exception will probably fit better than anything else.

To me, in this instance, (lazy) isn't a good enough reason to avoid adding the little, tiny bit of code required to make a custom exception when it's warranted...

Answer 4

Agreed that you should just write your own (heck, just type exception and hit Tab and the editor does 2/3 of the work for you!), but if not, I'd probably go with ArgumentException.

Answer 5

I see no reason not to use InvalidOperationException. Remember that unless your callers will do something programmatic with your exception, the exception type does not matter. For instance, if they are going to catch it explicitly, or reference some property of your exception, then you need one of your own.

Otherwise, the built-in exceptions will do fine.

---

See How to Design Exception Hierarchies by Krzysztof Cwalina, coauthor of Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries.

Answer 6

Since "throw new Exception" is now officially bad style and out of fashion, I throw InvalidOperationException("descriptive message") for all errors I'm too lazy to write a custom error for.