What Object is Causeing NilObjectException

Has anyone worked out a way to determine which object has caused a NilObjectException without having to code and test every object before use?

I error trap all my code and NilObjectExceptions occur because of bugs or setup issues rather than not testing for the existence of a file for example. What I was hoping for was something like this

Try

Dim MyDate As Date
MyDate.Year = 1950

Catch Err As NilObjectException

MsgBox "Object not set:" + Err.ObjectName

End Try

Try

I would like this code to display “Object not set: MyDate”

Am I missing something? Can Introspection be used?

Thanks in advance

Things to try

  1. Turn on break on exceptions and run in the debugger
  2. Put some logging code in the catch portions of your tries

I had a similar experience before on a server. What I ended up doing was install Xojo on the server and run the application via the debugger. Once the exception occurred, Xojo pointed right to the problem.

Putting Xojo onto the client’s server is not really an option unfortunately (especially as future versions can’t be loaded without a licence)

I do have logging code in my catches to tell me which routine I’m in but I just wanted to go a step further and find out which object was causing the problem.

Thanks

Narrow your tries down
Instead of

try
dim x as type

… lots of code …
end try

dim x as type

try
… line by line … or block by block where its important an object not be nil …
end try

Or just test right before you use ANY object that its not nil

Something like a global method called ASSERT is useful

Sub Assert(condition As Boolean, msg As String, additionalDetails As String = "")
  if not condition then
    Log "Assertion failed: " + msg
    
    #if not DebugBuild
      try
        raise new NilObjectException
      catch err as NilObjectException
           /// now do something useful with the stack trace like log it or email it or whatever
      end try
    #endif
    
    break // in debug mode this will stop here
  end if
  
End Sub

Then in your code where you EXPECT (or assert) that a certain set u should be true you can write

    assert obj <> nil, " Whoops OBJ is nil !"

This wont fix the NOE but it will identify it

Can you put the remote debugger stub on the client’s machine and debug remotely?

This is a good reason for the advice to prefer small, short methods / functions over long ones : if the method is only a few lines long, then the location of the exception often will be obvious.

Another technique I use is liberal logging:

Sub Foobar()
// a really long function
System.DebugLog(currentMethodName + " Start")
... some code....
System.DebugLog(currentMethodName + " At checkpoint alpha")
... some code....
System.DebugLog(currentMethodName + " At checkpoint beta")
... some code....
System.DebugLog(currentMethodName + " At checkpoint gamma")
... some code....
System.DebugLog(currentMethodName + " done")

And the actual logging is usually my own function that I can turn on or off, either at compile-time or runtime with a flag.