I just downloaded 2015 r4 to my Windows box and tried building an app.
Now I have the following problem:
When starting a built 32-bit app and start the main function of the application I immediately get a NilObjectException.
However:
I can run the application and debug it without problems and without getting an exception.
I can built a 64-bit version of the app and do not get this NilObjectException.
Problem appears to be 32-bit only.
System: Windows 8.1 64-bit,
The app is a logfile parser, so it does a lot of stream-stuff.
For now I solved the problem by adding an additional catch “NilObjectException” to the major try/catch-block of the main event loop.
For testing purposes I added a msgbox to the catch-block to see if it gets fired. The funny thing is: it does never fire. As soon as I remove the catch for the NilObjectException, it happens again.
It would be nice to know what is causing the problem though. So if you have any ideas how to look more closely into the problem I would be very grateful.
It was said somewhere that you’re not supposed to use MsgBox for debugging, instead use System.DebugLog.
Turn “Break on Exceptions” on and you’ll see what’s causing the NOE before the app dies.
I’d try & localized the issue a bit by putting checks for nil objects tightly around various bits of code
Since its a log file parser I’d put one around where you locate & open the file to see if you’re getting a nil for the file to open
In the IDE we have one nice little method called “Assert” that we use frequently to “assert” that certain conditions are true before proceeding
Its quite simple
[code]Sub Assert( condition as boolean, message as string)
if not condition then
system.debuglog message
break
end if
end sub
[/code]
Then in the main code you can write
dim f as folderItem
// ... some code to set up the folder item
// now check that before you proceed F is NOT nil because the rest of the code relies on that being true
assert f <> nil, CurrentMethodname + " has a nil folderitem"
and you can leave that code in for runtime and will get a message logged to the console on OS X or in DebugView on Windows that you can use to track down whats wrong