NilObject problem

i have been having a problem with NilObject. it i want to walk through a run, i put a break at a point and it goes to there and when i take the first step, i get a nilobject. the line it rejected could be int1 = 1 and i have put a dim int1 as integer at the top of the module. also, if i move the break down stream, the program breaks at the new point and does not give me a nilobject before then and then gives me a nillobject when i take the first step onto a line that is ok and it had to execute the line that it broke at above. i have used xojo for years though not for a couple.

Can you post the code? (Please use the code tags so it’s formatted for us.)

i have a rather large program. i call a method to save a file like this

Dim Index, Id, int1 As Integer
Dim str2 As String
Dim f As FolderItem

bolSaveTraditionalResults = TRUE
bolCalcResidVolume = False

f = GetSaveFolderItem(“TEXT”,"")

If f = Nil Then Exit Sub

TOS = TextOutputStream.Create(f)

if bolSaveTraditionalResults = true then
TOS.WRITELINE strSaveLeadTraditional

i put the break at bolSaveTraditionalResults = TRUE and the variable is defined in the same module. when the program stops at the line, step in results in a nil object. if i move the break further down to the next line. i get to that line, then it gives a nil object


Interesting. What happens if you Step Over instead? Step In would be unexpected at that point, so maybe there’s an oversight or something going on.

i have used step in for years and never had this problem. i just tried step over and it gave me anil object also. i sure would like to figure out what is happening so i can get on with the program

It sounds like you’re getting the NilObjectException on the TOS.WRITELINE. When the debugger pauses, you see a list of variables and their values. Check that TOS isn’t nil.

I take it you’re declaring TOS and checking it’s not Nil?

Have you tried clearing the cache?

i seldom work in this area of coding, copying it from program to program

i am presently at and TOS is declared a global text output stream

Dim f As FolderItem
bolSaveTraditionalResults = TRUE
bolCalcResidVolume = False
f = GetSaveFolderItem(“TEXT”,"")
If f = Nil Then Exit Sub
TOS = TextOutputStream.Create(f)

i still get a nil object if i put a break on bolSaveTraditionalResults when i step in

how do i clear the cache?

i have responded to another comment by tim hare with a longer response. to you i will say no and how do i check if it is nil? thx

Actually, if you’re using 2019r2 or later, you actually need to wrap your code in a try-catch block and “catch” the nilobjectexception. Just checking for nil won’t work any more.

i am using the latest version. what is a try-catch block?

Some information:

thx. the break on nil objection led to errors i could not imagine and were not in the stream of code being viewed. hopefully that will fix my problem.

Is there some rationale for that?
Wouldn’t it make changing code from API1 to API2 risky?


Well that sounds like a major issue then. This should be headlined in the docs on each object…

1 Like

please could you explaining a little bit more? we all need/use this =nil universally.
it was only about the use of GetSaveFolderItem?

1 Like

I have 700 instances in the project I have open alone, taking account of
if x <> nil then
if x = nil then

Not all such cases are followed by code that could or would need to be trapped in a try…catch


if x = nil then
    msgbox "you need to do y"
end if

Try…catch doesn’t help there if we cannot rely on a test for nil

1 Like

Which is one of the irritating things about this exceptions-everywhere approach. I tend to put the IO operation (and nothing else) inside the Try.

Or you can do as I did with database methods. I already had my own wrapper around these, so I could encapsulate error logging without cluttering up the main code. So I hid the Try/Catch stuff in there too, and stuck with a single test after each database method call in the main code. Much cleaner.

1 Like

We were talking about TextOutputStream, but you’re right GetFolderItem probably still returns Nil.

That said, the FolderItem API 2 methods all throw exceptions now so you’ll be better off learning how to do that.