0

A frequent problem I run into is finding exceptions in my logs with messages like: 

Process: Ems.MailServer.Service    Exception occurred at line: 0    Exception: Object reference not set to an instance of an object.

Of course in a debug environment, you can step through and find the source of the problem, but when relying on logs, there is never a line number reported with the error. It is always "Exception occurred at line: 0".

Is there a way to log information that might give a line number, or the name of the null variable?

(Please don't answer with - "You should check for null", of course if there is any expection of a null variable, I will check, but it is not practical to check every variable)

Any advice appreciated.

gbro3n
  • 6,729
  • 9
  • 59
  • 100
  • Show us how you are logging this out? – Paddy Sep 12 '13 at 11:09
  • @grx - Stack trace might give more info on the exception – Bibhu Sep 12 '13 at 11:15
  • "it is not practical to check every variable" - it's that, or have some sort contract checking - like ReSharper's `[NonNull]` - in place, or just do not write methods that return null. (Throw an exception instead, and provide an explicit `TryWhatever()` method as an alternative.) – millimoose Sep 12 '13 at 11:18
  • How r u currently logging? If not do some sort of Logging – Kamran Shahid Sep 12 '13 at 11:18

3 Answers3

5

You should deploy your product together with its pdb files. This way you'll get the line number information correct.

Gil Rici
  • 101
  • 1
  • I'm not sure how great of an idea it is to have your costumers have your pdb files. – Omri Btian Sep 12 '13 at 11:17
  • 2
    @Omribitan Are you afraid they'll hack the app they paid for? The OP's error message implies this is some sort of mail server which makes this even less of an issue. – millimoose Sep 12 '13 at 11:19
  • In this scenario, this option is available, and is a straight forward solution. Thanks. – gbro3n Sep 12 '13 at 11:33
  • IF you are scared of people having your pdb files, then ensure you can recreate the issue and use a symbol server to store the PDB`s for your various releases – chris warner Sep 12 '13 at 12:07
3

Log out a stack trace with the exception (this is standard practice to be honest). This can be found as the StackTrace property on the exception object.

If you want line numbers check this post out: Display lines number in Stack Trace for .NET assembly in Release mode. In short, you will need to deploy the PDBs with the Application/DLLs.

Community
  • 1
  • 1
Conor Gallagher
  • 1,500
  • 2
  • 19
  • 42
  • Stack trace is included, just not in my post. Only additional info is at etc. Including PDB files is the option I'll be going with though. Thanks. – gbro3n Sep 12 '13 at 11:36
  • No problem. Although I should add the question somewhat changed after I posted this answer! – Conor Gallagher Sep 12 '13 at 11:44
0

If you have control over the log output, and you have a top most application code (e.g. main method) then there you should add a top most level try catch, and should try printing the StackTrace of caught exception into the log. This stack trace would tell you the whole error propagation starting with its origin.

In particular your case, your should catch NullReferenceException exceptions.

You can also try useful answers from this post.

Community
  • 1
  • 1
Purnil Soni
  • 831
  • 4
  • 18