When to use InvalidOperationException or NotSupportedException?

Question

I am implementing a custom collection implementation that can either be readonly or non-readonly; that is, all the methods that change the collection call a function that is the moral equivalent of:

private void ThrowIfReadOnly() {
    if (this.isReadOnly)
       throw new SomeException("Cannot modify a readonly collection.");
}

I am not sure which of NotSupportedException or InvalidOperationException I should use in that case.

Answer 1

The MSDN only has one bit of guidance on this precise topic, on NotSupportedException:

For scenarios where it is sometimes possible for the object to perform the requested operation, and the object state determines whether the operation can be performed, see InvalidOperationException.

What follows is purely my own interpretation of the rule:

• If the object's state can change so that the operation can become invalid / valid during the object's lifetime, then InvalidOperationException should be used.
• If the operation is always invalid / valid during the whole object's lifetime, then NotSupportedException should be used.
• In that case, "lifetime" means "the whole time that anyone can get a reference to the object" - that is, even after a Dispose() call that often makes most other instance methods unusable;
  • As pointed out by Martin Liversage, in the case of an object having been disposed, the more specific ObjectDisposedException type should be used. (That is still a subtype of InvalidOperationException).

The practical application of these rules in that case would be as follows:

• If isReadOnly can only be set at the time when the object is created (e.g. a constructor argument), and never at any other time, then NotSupportedException should be used.
• If isReadOnly can change during the lifetime of the object, then InvalidOperationException should be used.
  • However, the point of InvalidOperationException vs NotSupportedException is actually moot in the case of implementing a collection - given the description of IsReadOnly on MSDN, the only permitted behavior for IsReadOnly is that its value never changes after the collection is initialized. Meaning that a collection instance can either be modifiable or read-only - but it should choose one at initialization and stick with it for the rest of its lifetime.