0
try
{
     list = from XElement e in d.Descendants(wix + "File")
            where e.Attribute("Name").Value.Contains(temp.Name) &&
            e.Parent.Parent.Attribute("Name").Value.Contains(temp.Directory.Name)
            select e;
}
catch (NullReferenceException e)
{
     MessageBox.Show(e.Message);
}
catch (Exception e)
{
     MessageBox.Show(e.Message);
}

now my question is why does this code produce a run time error saying I have a NullReferenceException unhandled. If you need more information about the program let me know.

EDIT: The debugger points to the "where" part of the linq statement. When I run this program direct from the exe file I still get the exception.

Christopher B. Adkins
  • 3,361
  • 2
  • 23
  • 27
  • .NET 3.5 and d is a XDocument – Christopher B. Adkins Jan 04 '10 at 10:36
  • Please see my edit - it's just the result of deferred execution. – Jon Skeet Jan 04 '10 at 10:40
  • Remember, the result of a query expression is *an object which represents the query*, not *the results of the query*. You don't actually execute the query until you start asking it for results. If you want the query to execute immediately, stick a "ToList()" on the end of it. – Eric Lippert Jan 04 '10 at 14:50
  • @Eric: Is it better to add the execution into the try block, or remove the initialization from the try block and ONLY have the execution in it? – Christopher B. Adkins Jan 04 '10 at 15:17
  • 4
    Neither. You should NEVER EVER EVER catch null reference exception. If you have a null reference exception, you have a BUG. *Fix the bug*, don't handle the exception. Nor should you be catching all exceptions. Rework your logic so that you don't have to do the catch at all. – Eric Lippert Jan 04 '10 at 18:02
  • I have pre-compiled WiX data that I am working with. The logic is good for 99% of cases, but there is one or two cases where this will not work. Without changing the source at all I don't know how to fix this logic. Sadly changing the source is not allowed because then that would throw off other projects. And in my defense the catch all exceptions is only there while I was trying to figure out why the other error wasn't being caught. I ALMOST never use it. – Christopher B. Adkins Jan 05 '10 at 08:16
  • What if you want throw another exception as a result, for example the reference is null due to session expired – stuartdotnet Nov 20 '13 at 02:47

1 Answers1

7

EDIT: Okay, I think I know the problem... it's due to deferred query execution.

If you've just got the query construction in the try/catch block, that's not going to catch exceptions which occur while the query is being executed.

Look at the stack trace you've got, and you'll find that there'll be a stack frame where you're executing the query - it's just the auto-generated lambda expression which comes from this bit of code, and it's not running within the scope of the try/catch block.

ORIGINAL ANSWER:

Are you just seeing the exception in the debugger? If so, go into the debugger exception dialog and change the preferences for the point at which exceptions cause the debugger to "break". The catch block should be handling the NullReferenceException normally. (Admittedly I don't think you should really be catching NullReferenceException in the first place, and catching all exceptions like that is generally a bad idea too, other than at the top of the stack - but that's a different matter.)

Jon Skeet
  • 1,261,211
  • 792
  • 8,724
  • 8,929
  • The debugger points me to the "where" part of the linq statement. When I run this program normally (aka no debugger, just straight run) I still get the exception. Also just for the record I normally wouldn't be catching all exceptions like that either, but I have been trying to figure out why the more specialized exception wasn't working. – Christopher B. Adkins Jan 04 '10 at 10:18
  • @Adkins: Move the catch block to where it's *actually* executing... or call `ToList()` to execute the query eagerly and remember the results. – Jon Skeet Jan 04 '10 at 10:49
  • @Jon: Thanks a lot. I have been staring at that little bit of code for far too long. I added a foreach that actually worked with the code into the try block and now it works perfectly! – Christopher B. Adkins Jan 04 '10 at 10:51