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
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:
InvalidOperationException
should be used.NotSupportedException
should be used.Dispose()
call that often makes most other instance methods unusable;
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:
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.isReadOnly
can change during the lifetime of the object, then InvalidOperationException
should be used.
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.