Is static code verification for potential null object references available?

Question

I would like a way to get warnings when an object reference could potentially throw a Null Reference Exception, so that I can write defensive code for these.

I have looked at Resharper, but didn't see anything there that accomplishes this.

Code Contracts is probably a non-starter; the application is quite large, and it's written in .NET 3.5, before Code Contracts became officially available.

Vedi

Wouldn't it be easier just to always check to see if the reference to the object is null? You could also go another route, and make sure object you do use, cannot be null. – Wigan

For every object reference? :o Some of them will never be null (they are set in the constructor). – Vedi

Even if you're not using Code Contracts, you should be writing guard clauses at the beginning of your methods. – Mirnamirror

What does Code Contracts have to do with .NET 3.5? – Pyo

Answer 1

Resharper does in fact accomplish something like this. Possible NullReferenceExpections are highlighted in the IDE in blue, with tooltips when you hover over them.

Resharper then keeps track of potential errors and warnings in it's own inspection results window (separate from Visual Studio's compiler errors and warnings).

Priedieu

Will they appear in the analysis warnings list? It's possible they are being buried in a sea of other warnings. – Vedi

Oh I see what you mean. They will not appear in the VS Error List; Resharper maintains it's own window for navigating and keeping track of code issues. Updating my answer accordingly. – Priedieu

@RobertHarvey did you end up using ReSharper? I've just tried out the trial, to see if it picks up on a similar null-issue (it does), but by default it gave me a few thousand warnings/errors for the solution, a lot of which I don't care about. – Brickle

@Stijn: Yes, I tried it and yes, it does give a lot of warnings I don't care about, but you can filter and change your display settings to only see the errors you want to see. – Vedi

Answer 2

Generally speaking, unless you specifically initialized an object, It can always have the potential to throw a null object reference, at least as far as the compiler is concerned.

in order for an algorithm to check whether a reference to the object can potentially be null, it would have to traverse every possible path that your program can take, and that includes paths in any external libraries that you may be using. Even for the simplest of programs, such an algorithm would kill the performance of your compiler.

Fari

Well, it doesn't necessarily have to check every time I compile. Mostly, I'm looking for "first-chance" exceptions, not situations where an object is initialized, but may be set to null later (I seldom, if ever, do that). – Vedi

Answer 3

I'm against the idea of blindly defending against null for each field available in the code and inside each method.

The following help me deciding about where to check against null values:

1- Who will be invoking your methods?
If a method is private and you have control over how's it's being accessed, I don't see it makes sense to protect against null checks unless it's part of the method's logic to expect null values. If a method is exposed to the public (Such as an API), then of course null checks should be a huge concern.

2- Software Design:
Image you have are calling method1(fromAnimalToString(animal)); and for some reason fromAnimalToString() never returns null (Though might return an empty string instead).
Then in such case, it wouldn't make sense to check animal != null in method1()'s body

3- Testing:
In software engineering, it's almost impossible to test all possible scenarios that can ever execute. However, test normal and alternative scenarios and make sure the flow is as expected.

Pudgy

I'm asking because I've released the project a couple of times to testing, and null reference exceptions have appeared that were not apparent in my development testing. – Vedi

I think in an ideal environment, developers try their best to minimize bug occurrence. In case of complex system, it's the job of QA to try to produce scenarios developers did not think of so that that alternate scenarios can be found during the QA phase that might lead to possible NullPointerExceptions. In such cases, it may not be enough to check against null, but also to take the appropriate logical measures based on what caused the parameter to come as null. – Pudgy