FolderItem nil oddness

I recently encountered something strange when assigning a FolderItem in a Window Open event.

Dim f as folderitem f = SpecialFolder.Desktop.child("test").child("test.zip") If f <> nil then // do things // end if

When /Desktop/test/test.zip does not exists, it throws an NIL object exception at the code line f = SpecialFolder.Desktop.child(“test”).child(“test.zip”)
The code above shouldn’t give any error at all, not?

Of course I can catch it with a try/catch but imo the above should work fine.

You don’t indicate what // do things // is. Sometimes being a tad more specific would help a lot.

If you want to read, you should test Exists as well.

If f <> nil and test.exists then

True, but the thing is … it throws the error at the f = SpecialFolder.Desktop.child(“test”).child(“test.zip”) code line.
It doesn’t even come to checking for it being Nil.

[quote=326256:@Christoph De Vocht]True, but the thing is … it throws the error at the f = SpecialFolder.Desktop.child(“test”).child(“test.zip”) code line.
It doesn’t even come to checking for it being Nil.[/quote]

It is because the subfolder test does not exist ; yet you try to make it a child.

Do that sequentially.

OK, a quick test

Dim f as folderitem f = SpecialFolder.Desktop.child("test").child("test.zip")

Throws an exception error

Dim f as folderitem f = SpecialFolder.Desktop.child("test.zip")

Does not throw an exception.

This sounds like a Xojo bug, right?

You don’t understand.

If neither test nor test.zip exists the error is perfectly normal.

You should check first for “test”, then if it exists, check child("test").child("test.zip").

f = SpecialFolder.Desktop.child("test.zip")

to do this line, Xojo checks for a child of SpecialFolder.Desktop … which is not null, and so all is fine.

f = SpecialFolder.Desktop.child("test").child("test.zip")

to do this line, Xojo checks for a child of SpecialFolder.Desktop.child(“test”)
But that thing doesnt exist, so it is not possible to check if it has a child (it is null) and so you get an error.

Um, guys… that line should not throw an exception (unless SpecialFolder.Desktop is bad). Assuming SpecialFolder.Desktop is non-Nil and exists, then SpecialFolder.Desktop.Child(“test”) will be non-Nil. It may or may not exist, but worst case, SpecialFolder.Desktop.Child(“test”).Child(“test.zip”) will return Nil, but not throw an exception.

Yes, Tim you are right. I do not expect that this throws an exception error. This is a bug for sure. Will add a Feedback case.

I think if test does not exist, trying to test a child on a non existing folder should raise an exception. Hopefully Joe or another Xojo engineer will say what it should be.

Yes I know it returns nil but it should not crash the app with an exception when just setting the folderitem.

It doesn’t crash the app. It reports an exception that you can catch. A crash is what happens if you have no way to catch it, such as when you have bad pointers, causing a memory access violation. :wink:

It should IMHO. If test is nil, technically it makes sense to get an exception when you are trying to get a child from a nil object. But hey, you are free to file a feedback report to be told so.

Actually, wait a minute:

  f = SpecialFolder.Desktop.child("test").child("test.zip")

That code should not raise an exception even if “test” does not exist. It should just return nil.
At least it does in my test, on OS X. Where did you test this, Christoph?

That’s what I am trying to explain - see my original post. :slight_smile:

It is not normal if it crashes the app. It should only crash if you try to USE the folderitem.

BTW it’s on Windows. Will try later on macOS.

Update: Works as expected on macOS. It only seems to be an issue on Windows.

So the question is: What does SpecialFolder.Desktop return? Does it exist? Is it readable?

No.

I’m surprised that 90% of the posts on this thread either totally misunderstood the poor OP’s question or gave the wrong answer. There is no bug, this is intended and also very, very obvious if you’ve worked with REAL/Xojo any amount of time. Jeff Tullin got it right but everyone seemed to ignore it. I read this forum a lot less in the past year because of all this false information and wrong answers.

f = SpecialFolder.Desktop.child(“test”).child(“test.zip”) is doing multiple things in sequential order like Michel said. SpecialFolder.Desktop returns the Desktop folder item and it always exists. It then performs the method child(), and if that doesn’t not exist it doesn’t return Nil but a non-existent FolderItem, which is legal and often desired.

Now, maybe Xojo doesn’t doc it carefully enough (they probably do), but a FolderItem that is DEFINED but does not exist on the File System throws an exception when you try to perform the child() method. Of course a Nil Object Exception is worded falsely, but it is the best type of exception to call it and have thrown. When you think about this, it makes perfect sense and give Xojo reliability implementing it this way.

That is what’s happening here. Don’t call child() on anything other than a FolderItem that not only is not Nil but also Exist=True. And when you chain child() methods, you expose yourself to this type of thing. And don’t try-catch, that’s bad practice. Code it right.

Lesson: don’t chain your FolderItem.Child() methods. Bad practice.

No bug, Xojo=1, Users=0. =)

1 Like

Problem is, I tried all along to explain what you just summarized, but seems people don’t like that. They insist on looking for a child on a nil object.

Looking for any member on a nil object quite rightfully raises a Nil Object exception throughout the framework. There is no reason whatsoever why FolderItem should be different.

Somehow it seems that does not compute somewhere.

This triggers a very beautiful Nil Object exception on Mac, as expected :

[code]dim f as folderItem = SpecialFolder.Desktop.child(“Test”)

system.DebugLog f.child(“test.zip”).ShellPath[/code]

Right. If that returns nil or Exist=false, it makes all sense. Otherwise, it does not, as then it would behave differently on OSX vs. Windows.

So. Christoph, what’s the state of SpecialFolder.Desktop on your Win system?