Avoiding nulls with expression trees

I’ve blogged about this subject before, but I REALLY hate null refs. This is one of the reasons I love F# and other functional languages, null ref’s almost never happen. But, in the real world I work as a C# dev and have to live with C#’s… nuisances.

In the other post, a big problem with the dynamic proxy was that it only worked with virtual methods, so it wasn’t really all that practical. This time around I decided to try a different route and leverage expression tree’s to actually build out the if checks automatically.

For the impatient, full source available at my github and the library is available on nuget

Demonstration

Let me demonstrate the final usage first. If all of users properties and methods return null, executing this whole chain would fail starting at the null result of GetSchool(). But, by using the Option static class we can safely deconstruct and inspect the expression, returning if the chain is valid, what failed in it, and what was the final value (if one existed).

The return value of the Safe method is a new object called MethodValue which tells you if the expression was successful (i.e. no nulls), or if it did fail, what failed (i.e. where in the expression it failed). And of course if the chain is valid you can get the value safely.

The magic

The magic is actually pretty easy. Because we have access to the expression tree we can rewrite it however we want. If you aren’t familiar with expression trees, the idea is that the compiler can convert a lambda into it’s abstract syntax tree. That means you can traverse it (with a visitor) and know information about the objects.

Since we need to know the information about the whole call chain we need to iterate over it all first. As we iterate we should track of what happened in the call chain so we can re-iterate over it later and manipulate it at the end.

In the process of visiting the nodes, we pushed each piece of the call chain into a stack. Now we can build it all back out. The bulk of the work is in this recursive function. It iterates back through the stack, maps the previous call to a variable, and builds out if not null checks.

The initial statement “user” needs to get assigned to a variable. Then this variable needs to be transformed into a new call where we call “.school” on it. We know what to do with “.school” because the call for “.school” was captured as part of the stack iteration. During the iteration of the expression tree in the visitor we were able to capture each portion of the tree.

Look:

Given that we have each piece we can now inspect it and manipulate other pieces with it

Conclusion

Building expression tree’s was a little complicated. There aren’t any return statements, and I ran into a lot of weird errors assigning and accessing variables (you need to use certain overloads of the block expression, which I only figured out after reading a jon skeet answer on stack overflow). Still, the resulting code is concise and clean, and until the .? operator shows up this isn’t a bad alternative!