How to prevent NilObjectExceptions on Quit?

[Julia_Truchsess]

@Arnaud_N

@Julia_Truchsess

I still think the framework could/should do this: if the the app is quitting, automatically remove all handlers, and destroy timers, sockets, and SerialConnections before anything else.

Wouldn’t that prevent one foreseeing how the code will work/fail, especially if the destruction order isn’t predictable or expected?

Not sure I understand your point. The framework already has some kind of sequence, hidden from users, for destroying objects when an app quits (or when a window closes, I guess). All I’m saying is that that sequence could be designed so that objects that can fire events at random (and therefore cause NOEs if not destroyed first) are destroyed first. How would that interfere with development?

[Arnaud_N]

It would have to only concern WeakAddressOf/AddressOf then. I find those already too limited, especially that you can’t check for nil.

[Tim_Hare]

With WeakAddressOf, you can check for nil.

[Sam_Rowlands]

This is not rude, this is actually expected behavior.

[Arnaud_N]

Ok. It’s true I don’t use them as enough as I probably should.
Thanks for pointing that out.