Brad Abrams posted on the NullReferenceException or ArgumentNullException question. For me, it's one of those "close call" questions. The ArgumentNullException gives an immediate and clear indication that the method at the top of the stack trace has been called incorrectly. On the other hand, the stack does provide heaps of information on the cause of an exception and why perform a double check (by the app code and the automatic null checks the clr performs)? My general conclusion would be to enforce it (in FxCop or similar) on the public methods of public classes in a DLL.
The PrintValue method example Brad used brought to mind the recent discussions on AOP on Eric Gunnerson's blog. The theme that relates the two posts is the entry of what I would call "plumbing source code". Plumbing source code is repetitive code that needs to be entered into a variety of locations in source code and can't easily be separated out using standard methods or templates (C# 2.0). Examples of categories of plumbing code are listed in my recent post on AOP. Argument null checks are another form of source code that falls into the plumbing category.
I feel that there is a need to improve .NET developer productivity by minimizing plumbing code but still retaining performance and gaining in the maintainability area. Performance can be retaining by (say) limiting what the developer has to type to an attribute declaration but still having the resultant IL include the appropriate plumbing code. The attribute makes it clear what IL pre/post processing is being performed during the compilation of the code which assists in code readability. The plumbing code definition can then be supplied in one location rather than every instance that a plumbing code template is required.
Source code generation based on attribute definitions would be one way of achieving what is being described here, though I would prefer functionality that is built in at the compiler level. Darren Oakey, in his comments on the Eric Gunnersion AOP post, mentioned the C/C++ pre-processor functionality intent being more useful than advanced AOP techniques. My interpretation of the comment was the need for something in between the mess that pre-processor functionality can initiate and the conceptual complexity of an AOP implementation.
This throught process brought back some memories of a C# compiler extension that generated additional IL code in methods based on attributes. I spent around 15 minutes in Google land trying to find a web page to associate with my vague memory. It's frustrating when you've got paid work to do, but just want to find that tiny information needle in the proverbial haystack. Eventually I found what I was looking for. It's just a matter of getting the right combination of words that reduce the result space to something manageable!
ResolveCorp make a product called Extensible C# that generates "inline" IL code in methods based on attribute declarations on the method and it's parameters. Coincidentally the example showed on the products page is the null check plumbing that started me off on this post. Though I liked the Extensible C# concept a lot, it's never been pursued because it's the sort of functionality that needs to be in the core compiler support from a maintenance perspective.
My conclusion is that there is a need from a variety of areas to automate plumbing code based on attribute definitions in the .NET languages. Hopefully Microsoft can look into these areas. Actually that brings to mind, ObjectSpaces and WinFS. Surely the application code that reference these APIs is a prime candidate for the functionality discussed here?
