[quote=222254:@Hamish Symington]I have someone reporting a NilObjectException on El Capitan. I’ve narrowed it down to one of these two lines:
theCompressedFile = SpecialFolder.Temporary.Child( theUUID+".zip" )
theCompressedFileName = theCompressedFile.NameWithoutExtensionMBS
Because of some other stuff in our project I think it’s the former.[/quote]
I doubt the first line can trigger the NOE. Unless theCompressedFile is a computed property that tries to process it.
Looks more likely the second line triggers the error, when NameWithoutEXtensionMBS tries to get the name and finds Nil. You may want to step through to confirm.
I agree with @Michel Bujardet - the first line should not be able to throw a NOE. But it could possibly return a nil, which when you try to call NameWithoutExtensionMBS will throw the NOE.
I was wondering if SpecialFolder.Temporary was nil for some reason?
Anyway, I’ve seen one other quit this morning which looks like it was on a .Exists for a file which I know doesn’t exist (e.g. SpecialFolder.Desktop.Child(“fish.blah”) ) so I’m wondering if there’s something slightly different about how that’s handled on El Cap which is throwing errors.
OK, I’ve been doing a lot of testing on this this morning. First up, a recap of what I believe to be true.
SpecialFolder.Temporary should always exist. It should never be Nil.
SpecialFolder.Temporary.Child( ) should always return a folderItem, never Nil. That folderItem may not exist, but it won’t be Nil.
Now, looking at the code above:
theCompressedFile = SpecialFolder.Temporary.Child( theUUID+".zip" )
theCompressedFileName = theCompressedFile.NameWithoutExtensionMBS
the only way I can see that a NoE would be returned is if theCompressedFile is Nil. But I thought that it couldn’t ever be Nil. @Kimball Larsen , you say that it might return Nil; in what circumstances?
Somewhat banging my head against the desk on this one…
I think you may be right about this.
Previously the below code - deliberately without testing against being NIL - can throw a NIL object error.
This was not the case with 2015r2
Try
Dim f as folderitem = specialfolder.desktop.child(“test.txt”)
If f.exists then
Msgbox “hooray”
End if
Catch
Msgbox “not found”
End try
@Christoph De Vocht : I am working with 2015 r1. The problems are being reported on El Capitan only, as far as I can see.
I have just run your code 50,000 times and it’s not given me an NoE - but then I’m not getting any from mine either. So, I’m wondering if there’s something which very, very intermittently makes specialfolder. return Nil. If so, that’s going to be a massive pain, because we assume that everything from specialFolder will return a valid folder.
Ok its OSX10.11 related.
I somethings can trigger this, sometimes not.
But I have users complaining it happens always.
Of course I fixed this by testing it against being NIL
@Christoph De Vocht : How can you trigger it yourself? Should I run your loop more often? Is there anything which you can do to reliably trigger it?
My only thought for a workaround would be this: wherever I call SpecialFolder.Temporary (or SpecialFolder.whatever) I can replace it with a method called GetSpecialFolder(type as string) which I write myself. That gets the special folder and, if its Nil, loops until its not nil, then returns it. This has the great advantage that I can simply find and replace to implement the fix, rather than having to rework code to include Nil tests wherever I use specialfolder. However, if you say that there are some people who always complain that it happens, then SpecialFolder. will be nil for them always, in which case it’s hopeless.
[quote=222498:@Hamish Symington]@Christoph De Vocht : How can you trigger it yourself? Should I run your loop more often? Is there anything which you can do to reliably trigger it?
My only thought for a workaround would be this: wherever I call SpecialFolder.Temporary (or SpecialFolder.whatever) I can replace it with a method called GetSpecialFolder(type as string) which I write myself. That gets the special folder and, if its Nil, loops until its not nil, then returns it. This has the great advantage that I can simply find and replace to implement the fix, rather than having to rework code to include Nil tests wherever I use specialfolder. However, if you say that there are some people who always complain that it happens, then SpecialFolder. will be nil for them always, in which case it’s hopeless.[/quote]
Sounds like a winner.
Just a hunch, but worth verifying though : could it happen that theUUID be empty ? Then you could end up feeding NameWithoutExtensionMBS a FolderItem with no name. It is easy to verify if that kind of thing triggers a NOE.
Sorry @Hamish Symington - you are right. Your first line should NEVER return NIL. It could possibly return a folderItem that does not exist, which could in turn thrown a NOE on the second line. Sorry for my confusing language.