.NET: Which Exception to Throw When Required Property is Not Set?

Question

Assume I have a class like this:

public class Foo
{
    public Bar RequiredProperty { get; set;}

    public void Baz()
    {
        if (this.RequiredProperty == null)
        {
            // Which exception should I throw?
        }
    }
}

My solution has a class that is designed to be reused without having to pass a lot of arguments to the Bar method over and over again. So, what should I throw when Bar isn't initialized to a non-null value?

More Information I'm essentially rolling my own code parser and formatter. Call it an object lesson. One of the classes is an HtmlCodeFormatter that has the following properties (in honor of Dependency Injection):

public IFormatter Formatter { get; set; }
public IParser Parsre { get; set; }

This allows me to write any number of language-specific parsers and formatters. For example, I have a CSharpParser and a JavascriptParser. I also have an HtmlCodeFormatter, and there are plans for another (of dubious utility).

The idea is that you can instantiate the HtmlFormatter using an object initializer, like this:

var formatter = new HtmlCodeFormatter()
    {
        Parser = new CSharpParser();
        Formatter = new HtmlCodeFormatter();
    };
formatter.Format("Console.WriteLine(\"Hello, world!\"));

When HtmlCodeFormatter.Format is invoked, it needs to be able to verify that both a parser and a formatter have been provided. That's no problem, really, but I'm kind of stumped about which exception to throw. I'm leaning towards InvalidOperationException, but I'm not entirely certain that's the best choice.

Why don't you pass them in in the constructor? Are there that many properties that passing them to the constructor becomes hard to read? — CodesInChaos, Mar 05 '11 at 19:55
@CodeInChaos: Good question. It's a matter of taste in this case. Personally, I find object initializers to be far more readable. — Mike Hofer, Mar 05 '11 at 19:58

score 15 · Accepted Answer · answered Mar 05 '11 at 19:55

15

I would throw a InvalidOperationException. The MSDN definition is:

The exception that is thrown when a method call is invalid for the object's current state.

However, i recommend using constructor injection instead of setter injection. This makes sure you has valid parsers and formatters. If null is passed in the constructor, throw a ArgumentNullException.

answered Mar 05 '11 at 19:55

alexn

57,867
14
111
145

2

Jon Skeet agrees. I'm sold. (See: http://stackoverflow.com/questions/1903105/which-exception-to-throw-when-a-method-try-to-use-a-field-that-can-be-null). – Mike Hofer Mar 05 '11 at 20:04
Spot on then, wonderful! – alexn Mar 05 '11 at 20:23

score 7 · Answer 2 · answered Mar 05 '11 at 20:16

By using Propery Injection you are implicitly telling the compiler, fellow developers as well as DI Containers that the dependency is optional. This is because no-one forces you to assign a property value.

If the dependency is truly required, you should refactor to Constructor Injection. This will effectively make the dependency required:

public class Foo
{
    private readonly Bar bar;

    public Foo(Bar bar)
    {
        if (bar == null)
        {
            throw new ArgumentNullException("bar");
        }

        this.bar = bar;
    }

    public Bar RequiredProperty
    {
        get { return this.bar; }
    }

    public void Baz()
    {
        // this.bar is now GUARANTEED to be initialized,
        // so no checks are required
    }
}

Notice that the constructor Guard Clause (throwing an ArgumentNullException) effectively protects the invariants of the class, which is further strengthened by the readonly keyword.

With the dependency part of the class' invariants, you no long have any temporal coupling and you can now implement all members without worrying whether the dependency has been assigned or not.

I can definitely see your point, but I was under the impression that it's A Very Bad Idea™ to throw exceptions in a constructor, and that it was to be avoided At All Costs™. — Mike Hofer, Mar 05 '11 at 20:34
Not at all. The principle is called Fail Fast. Where did you get that idea? — Mark Seemann, Mar 05 '11 at 20:47
You know, I don't really know. There *is* the nagging chance that I'll get a TypeInitializationFailed exception, which might mask the real problem. But I *am* a fan of fail fast, so I've fixed my code with your guidance in mind. — Mike Hofer, Mar 05 '11 at 20:52

score 1 · Answer 3 · answered Mar 05 '11 at 19:55

1

You could throw NotInitializedException.

answered Mar 05 '11 at 19:55

decyclone

30,394
6
63
80

What namespace is NotInitializedException in? – Moffen Apr 08 '19 at 03:30

.NET: Which Exception to Throw When Required Property is Not Set?

3 Answers3