Comments on: Coding: Assertions in constructors

By: Coding: Checking invariants in a factory method at Mark Needham

Coding: Checking invariants in a factory method at Mark Needham — Sat, 05 Sep 2009 14:47:13 +0000

[...] after that I suggested that I didn't think it should go in the constructor of an object but that we should rely on objects to be good citizens and not pass in null values or the like to [...]

By: Jacob Stanley

Jacob Stanley — Fri, 20 Feb 2009 00:34:33 +0000

Looks like the and code formatting were stripped out of the example, but you get the idea

By: Jacob Stanley

Jacob Stanley — Fri, 20 Feb 2009 00:31:14 +0000

Checking constructor arguments can be done in a fairly non intrusive way with extension methods.

I use an extension method in the form – T NotNull(this T, string) – which allows for the following syntax:

public ControllerContext(HttpContextBase httpContext, RouteData routeData, ControllerBase controller)
: base(httpContext, routeData)
{
Controller = controller.NotNull("controller");
}

Tagged with the right attributes (from JetBrains.Annotations), ReSharper will even give you intellisense on the string which represents the parameter name.

[DebuggerHidden]
[AssertionMethod]
public static T NotNull(
[AssertionCondition(AssertionConditionType.IS_NOT_NULL)] this T argument,
[InvokerParameterName] string argumentName) where T : class
{
if (argument == null)
{
throw new ArgumentNullException(argumentName);
}

return argument;
}

By: Mark Needham

Mark Needham — Mon, 16 Feb 2009 13:40:02 +0000

"Hhhmmm … does the server-rule about client data submission apply here?"

Good point, I guess the boundary of client/server would be an area where I wouldn't trust the data coming in.

Re: Developers on the team etc – that was exactly the discussion being used in favour of having the assertions when we talked about it in the book club.

I'm not sure what the answer is – I've not worked on a project where we put these types of assertions throughout the codebase, it would be interesting to see how it worked out.

By: Paul

Paul — Mon, 16 Feb 2009 13:32:30 +0000

"we would assume that our classes are good citizens"

Hhhmmm … does the server-rule about client data submission apply here?

We always tell our server-side developers not to trust the client input, to always validate it: The client is always either stupid or malicious.

Without validating the inputs, we're assuming that both current and future callers will be "good citizens" — but how many developers are on the team? How many maintenance developers will fix defects and add features to this codebase over the next five or ten years?

Will they all develop code that meets the "good citizen"-test and what the potential consequences of them not doing so? Just a null-pointer exception or something more serious?

I don't think the readability argument holds water, because the potential consequences if there's a situation where null results in an unexpected result, rather than an exception, could be high.

By: Reflective Perspective - Chris Alcock » The Morning Brew #287

Reflective Perspective - Chris Alcock » The Morning Brew #287 — Mon, 16 Feb 2009 08:37:34 +0000

[...] Coding: Assertions in constructors – Mark Needham considers the need for assertions to catch null references passed into constructors, and questions if this is a good idea [...]

By: Arjan`s World » LINKBLOG for February 14, 2009

Arjan`s World » LINKBLOG for February 14, 2009 — Sat, 14 Feb 2009 22:01:35 +0000

[...] Coding: Assertions in constructors – Mark Needham ' I suppose this is a limitation of the Java/C# type system that you can't prevent null values being passed into a constructor or that you can even have a null value in the first place ' [...]

By: Jeremy D. Miller

Jeremy D. Miller — Fri, 13 Feb 2009 17:40:03 +0000

My opinion is that the null ref argument checks are just unwieldy code noise. I think the MVC team is doing that because of a coding standard more than a real need. On any project that I do, all dependencies are generally filled by an IoC tool, so the threat of an NRE is effectively nil. In that case, the null checks do more damage to readability than good in terms of error prevention/detection.

I think the MVC code is a poster child for the negative impact of defensive coding. I find that code to be very hard to follow because of the overwhelming defensive code checks.

Besides, it's nice to be able to throw in nulls in unit tests when a dependency isn't really in play.