Menu
if one takes a look at the decompiled source of the .net framework code most of the APIs have checks like these
if (source == null) throw Error.ArgumentNull("source"); on the method arguments instead of using a more generic class like
Guard.IsNotNull(source); Is there a reason behind doing this explicilty every time or is this just legacy code that is been around since the framework was developed and the newer classes are moving towards this or are there any inherent advantages of having explicit checks? One reason that I could think off is probably to avoid overloading the stack with function pointers.
547
Guard clauses are true/false expressions (predicates) found at the top of a method or function that determine whether the function should continue to run. Guard clauses test for preconditions and either immediately return from the method or throw an exception, preventing the remaining body of code from executing.
Code contracts provide a way to specify preconditions, postconditions, and object invariants in . NET Framework code. Preconditions are requirements that must be met when entering a method or property.
NET 4.0. Code Contracts API includes classes for static and runtime checks of code and allows you to define preconditions, postconditions, and invariants within a method.
Code Contracts provide a language-agnostic way to express coding assumptions in . NET programs. The contracts take the form of preconditions, postconditions, and object invariants. Contracts act as checked documentation of your external and internal APIs.
In simple language we can say that the code that validates your method's input is called a Guard clause. It makes your code more understandable and it protects you from bugs and unexpected behaviors. The if block act as a guard clause by protecting the GetStudent method against any null _student arguments.
There's no Guard class in the .NET framework so your proposed alternative is not feasible. Later additions to the framework do use code contracts, but rather sparingly. Not every .NET programmer at Microsoft seems that convinced that contracts are that useful, I do share the sentiment.
Although compiling an expression tree is an expensive operation, it is a convenient alternative that can be used in applications that are not performance-critical. With Guard, if you want to guard an argument against null or max length, you just write NotNull and MaxLength and that's it.
With Guard, if you want to guard an argument against null or max length, you just write NotNull and MaxLength and that's it. If the argument is passed null, you'll get an ArgumentNullException thrown with the correct parameter name and a clear error message out of the box.
Adding to Matthews answer:
Your proposed syntax of Guard.IsNotNull(source); is not directly equivalent to the first code snippet. It only passes the value of the parameter but not its name, so the thrown exception can't report the name of the offending parameter. It just knows that one of the parameters is null.
You could use expression trees - like so: Guard.IsNotNull(() => source); - but analyzing this expression tree has a rather large performance impact at runtime, so this isn't an option either.
Your proposed syntax could only be used in conjunction with a static weaver. That's basically a post-compiler that changes the generated IL. That's the approach Code Contracts are using. But this comes with its own cost, namely:
71
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
