Question

I am trying to find the right way to write code regarding checking for the invalid values. Invalid value, in my case, would be null. The thing with other questions in SO is that they fall under specific circumstances and I am interested in a more general solutions.

I have a code like this:

public class SomeClass
{
    private readonly object m_internallyUsedObject;
    private ThirdPartyObject m_user; // Third party object.

    public SomeClass(object internallyUsedObject)
    {
        m_internallyUsedObject = internallyUsedObject; // We just want to ensure that the object will remain the same throught the life time of SomeClass object.
        m_user = new ThirdPartyObject(); // This object is not yet needed here.
    }

    public void DoSomething()
    {
        m_user.DoSomethingElse(m_internallyUsedObject); // Now we're using it and we are not sure whether null value is tolerated.
    }
}

Since we take the internallyUsedObject in constructor, we probably know the semantics of this object and how it should be used. On the other hand, we just relay this object to a third party object during calls.
Our SomeClass object will work just fine regardless of whether the value is null or not.

Now, the problem is that we do not know whether null will always work for the ThirdPartyObject – it might work in one version (in which case it’s OK to omit null check) and do not work in another.

One could say that we should not care for checking for null if our class can handle it. But when I write the code documentation, I would like to tell the user the behavior and expectations of our own class.

As I mentioned above, this simple check might not be useful or even invalid in particular third party object’s versions:

if (internallyUsedObject == null)
{
    throw new ArgumentNullException("internallyUsedObject");
}

Is it valid according to the OOP to take the internallyUsedObject from the code above inside the constructor when we are not going to use it directly? Doesn’t it violate the “fail fast” principle, since it might appear that we are just deferring the problem to the later stage of the object’s life time?

Answer 1

As a rule I’ve tended to use the method you’ve described in the second code block, but in combination with sensible groupings of checks. By this I mean that certain checks for particular methods should be performed and actions taken before an logic is performed e.g.

public void MyMethod(MyObject input) {

    // 1. perhaps security checks, if an in method security is required
    if(security.AccessLevel < requiredLevel)
        throw new CustomSecurityException("Insufficent Access");

    // 2. data checks
    if(input.Property == null)
        throw new ArgumentNullException("Input didn't contain the value I wanted");

    if(input.Property2 < someImportantLevel)
        throw new CustomBLException("Input didn't meet required level for something");

    // 3. perform BL
    // ...do whatever

}

It’s probably not ideal and often things like method attributes could be used for the security side of things but in quite a few of our apps this has seemed like a sensible grouping of checks. You know that all the checks are done up front rather than lengthy blocks like this:

if(input != null) {
    //do logic
} else {
    throw new Exception();
}

Where the checks could be hidden or nested and harder to locate.