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.
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.
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.
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.
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.
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.
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?
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.
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”)