Eric Gunnerson wants to know how we would like to avoid Null Argument exceptions.

I see this as related to Design-By-Contract. DBC has 3 checks: preconditions, postconditions, and invariants (both pre and post), so only 2 checks are needed and a mechanism to signify both to run. The Null Argument check is a precondition, or maybe an invariant. How is that related to AOP? Well, pre and postconditions are just code interception in one of the simpler models proposed by AOP proponents; messing with code at the beginning and end of the method is the very minimal AOP implementation. Many are more grandiose than that, being able to change code throughout the running of the method (or class, etc.). So perhaps the deeper question is how should C# support AOP, if at all? I'm not prepared to answer that. :)

A more pragmatic answer to Eric's question is what is the purpose of checking for null? I usually see it as a "developer exception", in that the developer accidentally sent you a null object when they were developing the application. In this case a NonNull attribute would be fine. How should this behave in a production environment? I would say the same. In fact, this implementation gives the developer metadata to check, versus just looking at the documentation or trial and error. So I'm all for the simplicity of an attribute!