Geek Answers Handbook

How can this code throw a NullReferenceException?

I have to go crazy because my unit tests fail because the following code throws a null ref exception:

int pid = 0; if (parentCategory != null) { Console.WriteLine(parentCategory.Id); pid = parentCategory.Id; }

The line that throws it:

 pid = parentCategory.Id;

The .writeline console is just debugging in the NUnit GUI, but it outputs a valid int.

Edit: single-threaded, so it cannot be assigned a null value from some other thread, and the fact that Console.WriteLine successfully prints this value indicates that it should not be thrown.

Edit: relevant fragments of the Category class:

 public class Category { private readonly int id; public Category(Category parent, int id) { Parent = parent; parent.PerformIfNotNull(() => parent.subcategories.AddIfNew(this)); Name = string.Empty; this.id = id; } public int Id { get { return id; } } }

Well, if someone wants to see the full code, it's on Google Code at http://code.google.com/p/chefbook/source/checkout

I think I will try to restart the computer ... I saw pretty strange things fixed by rebooting. Will be updated after reboot.

Update: The mystery has been resolved. It seems that NUnit shows the error line as the last successfully executed statement ... Copy / paste the test into a new console application and run in VS, showed that it is the line after the if if block (not shown) containing null ref. Thanks to everyone for the ideas. +1 to everyone who answered.

+4
source share
8 answers

It seems that NUnit shows the error line as the last successfully executed statement ... Copy / paste the test into a new console application and run in VS, showed that it was a line after the if statement block (not shown) containing a zero link Thank you all for ideas. +1 to everyone who answered.

0
source

Based on all the information so far, I think the “line that throws” is incorrect (which makes you think), or perhaps your “sources” are not in sync with your built-in assemblies.

This seems impossible, so some of the “assumed assumptions” are erroneous, and it is probably the assumption that “the source code you are looking for matches the process you are debugging”.

+7
source

When things look right on the surface, then this is probably what you get fired. Are you 350% sure that your DLL / PDB matches your source code, giving you the right line?

  • Try manually deleting your assemblies and running whatever you use. Is that not how it should be?
  • Try to clear your solution and recompile. Copy the builds there and run again. Does this work this time? Null ref in the same place?
  • Debug surrounding lines for expected values. parentCategory etc. should match what you think.
  • Change the code by throwing an exception. Does the stack trace lines exactly match your code lines?

I had some incredible impressions like this because one of my assumptions was wrong. Typical is an outdated assembly. Ask all the assumptions.

+3
source

However, it makes no sense that the OP claims that console.writeline prints a valid int, and it calls the same property as the line in which it indicates that an error is occurring.

The stacktrace element would be useful or could look at the actual unit test.

+2
source

Yes, is it possible to see the code for the class class ... in particular, the Id property? Assuming the Id property is int (and not nullable int), the get method must have access to the NULL object.

+1
source

Id can be a null type int (int?) Without a value, however I feel that the property identifier should do more than just return an int, and something inside should be null.

EDIT . Your editing shows that this is more than strange, could you provide us with a stack trace?

+1
source

I'm not an expert in C #, and not sure if it matters, but are you debugging Debug or Release mode? If you are in release mode, the line that your IDE points to and the line that the problem is on may be different (I know this is the case in C ++ when using Visual Studio)

+1
source

I need to agree with Brian ... Maybe you are using legacy .pdbs, and the code you see in debug mode does not match the really debugged code.

Try to clear the project and rebuild it in debug mode.

+1
source

More articles:


All Articles