December 4, 2012

Null + Type Checking: The Bad, The Ugly, and The Good

It is often the case that one must check for nulls and types at the same time. Over the last couple of weeks I've been both reading and writing code that checks for nulls and types for various subclasses throughout a codebase. Let's review some of the ways that one might perform such checks in order to execute conditional code branches:


The above code is just bad. Really bad. OMGWTF?!? bad. Yet, it's probably what I come across most often in code reviews. The reason it's bad is because the cast will throw an unhandled InvalidCastException if BaseClassInstance is not, in fact, an instance of SubclassType. Okay, so we know we need to handle that exception now, right? Let's try it again.


Alright, so technically the above code works and meets our requirements, but it's inelegant. We don't really want to be catching an InvalidCastException as a means of determining whether the types match. We can do better by removing the explicit cast.


Whoa... that's a lot of code to just check for a type and value. I mean, yes, it's technically correct and meets requirements, but could you scan that really quickly in a review and know what the hell was going on?


The above code is semantically the same as the previous example, but is clearly much more concise. The is keyword checks that an instance of a reference type is not null, and that it is of the specified type. So from now on, use the is keyword whenever you want to check for nulls and types in the same conditional expression.
Post a Comment