Error #0 for app.UnhandledException()

In one of my apps, I have an app.UnhandledException() event handler “just in case”. Very rarely, and only on Windows (app is compiled to Win and MacOS), this event gets fired, and the error passed to it has error.ErrorNumber = 0, and error.Message = "".
Any idea what could cause that sort of an error?

Ok, well, it looks like the error is caused when setting the property of a control on a Window that’s in the process of closing. Tough one to find as it depends on timing - the Window closes before the routine finishes in Windows, but only sometimes, and on MacOS that never happens…

Shouldn’t it still be a NilObjectException though?

Would seem it should be but … I’d hazard a guess there’s a bug in the framework

But thats JUST a guess :stuck_out_tongue:

Is it not?
You said ErrorNumber=0 and Message=“”, but that doesn’t mean the exception type isn’t a NilObjectException (I’d expect it is).

To avoid the exception, the very first line of the offended method can read “if LblPrompt<>nil then” (where “LblPrompt” would be the name of a control on the window). Avoid the rest of the code if it’s nil (if that suits your needs).

I’ve seen unclassified exceptions on Windows when dealing with URLConnection as well. It seems like it’s not the problem here since you’ve discovered the controls issue, but I wanted to share my experience running into incorrectly unclassified exceptions on Windows only.

1 Like

What is the Error # for a NilObjectException?

FYI: I also occasionally get random NOE when using URLConnection on the macOS. They have identifying information apart from they came from the Xojo class and that’s that.

My guess is it’s a bug within the Xojo framework.

theres not necessarily an error # for a NOE
dont rely on the error # for a lot of things
it could be a Xojo number, or an OS error code, IF its set at all

Well, I do use URLConnection in this app, so perhaps it’s related… BUT, the error only happens in Windows and adding
if TheControl <> nil
fixes it, so…

Yeah definitely avoid trying to touch ANYTHING to do with controls in a windows “Close” event
By then the controls have probably been deleted

Checking for a nil control is not a bad thing

1 Like