Question

I understand the use of CanExecute() and Execute(), but I’m wondering about the following scenario:

public class MyViewModel : NotificationObject
{
    public MyViewModel()
    {
        FooCommand = new DelegateCommand(DoFoo, CanDoFoo);
    }

    public Bar MyBar { get; set; }

    public DelegateCommand FooCommand { get; private set; }

    public Boolean CanDoFoo()
    {
        return (MyBar != null)
    }

    public void DoFoo()
    {
        MyBar.BarFunc(); //Potential for a NullReferenceException
    }
}

Basically, a consuming view could decide to call directly into the DoFoo method (obviously breaking the point of the ICommand interface) and cause a NullReferenceException. This may be a bit subjective, but I’m hoping for a “standard” way of doing it.

Do we:

1. Prevent the possible NullReferenceException by doing a if (MyBar != null) first?
2. Prevent the possible NullReferenceException by verifying that CanDoFoo() returns true?
3. Assume that the consuming view is behaving properly and has already verified that it can call into the DoFoo() method?

---

As a side note, the primary reason I asked this is because when I was writing unit tests I realized that someone could break my ViewModel by calling Execute() methods without calling their CanExecute() counterparts? Obviously in my unit tests I check to see that I can execute the method before doing so, but consuming views might decide to ignore that.

---

Update: (Scenario 2)

As an expansion to this question, I also want to add in the scenario where the DoFoo() method does not break in terms of exceptions, but could break logically?

public class MyViewModel : NotificationObject
{
    public MyViewModel()
    {
        FooCommand = new DelegateCommand(DoFoo, CanDoFoo);
    }

    public Int32 Age { get; set; }

    public DelegateCommand FooCommand { get; private set; }

    public Boolean CanDoFoo()
    {
        return (Age >= 21)
    }

    public void DoFoo()
    {
        ProvideAlcohal(Age);
    }
}

This second scenario does not actually break (the command can process fine), however, it breaks down logically. So, do we validate the business logic a second time by calling CanDoFoo() or assume the consuming view is behaving? (Remember, this only breaks the business logic).

Basically it boils down to this… Do we put in preventive measures to ensure the consuming view is not shooting itself in the foot by misbehaving?

Answer 1

Any implementation of command calling in WPF or Silverlight will do this, so you don’t have to worry about it from the UI system…

But it is a public method. Checking for null is one of the fastest things you can do. It doesn’t hurt and it is much more safe since you will throw a null exception without the guard clause.

Semantically, CanExecute may be implemented differently than a null check, so I would just do the null check in the Execute method, not necessarily check CanExecute.