How can FileQuit error?

I have debug logging in my app
Some users debug logs are getting an error from this piece of code, which is the entire code in the App’s FileQuit menu handler.

[quote]if keyboard.AsyncAltKey then
//do something
end if
RequestedQuit = true
quit
exception
writelog “error in filequit”[/quote]

Given that the ALT key is not being held at the point when the File/Quit menu item is used, and RequestedQuit is a simple boolean App-level variable,
how can this code fall into the exception and produce a log entry of “error in filequit” ?
Its one IF on the keyboard object and one assignment to a boolean.

what purpose does “RequestedQuit” have? since the app wil terminate, nothing can ever access it, so why set it?

and does the “do something” possibly abort the quit?

Did you add a Keyboard Handler for your Windows Quit MenuItem ?

@Paul: have a look at the LR text for MenuItem.PCAltKey.

It’s definitely not being called, but it has its own exception handler and wouldn’t cause an exception in this calling routine.

A good question.
In fact, it isn’t used at all , anywhere.
But its a simple boolean rather than a computed one.
I’ve just removed it.

That must narrow this down to ‘can the keyboard object ever be nil’?

I don’t know if it can… but why not add a check to see??

I’ve wrapped it in :
if keyboard <> nil

It is never nil on my machines, and it never errors on my machines.
But customers, eh?

@Jeff Tullin , did you try with a bluetooth keyboard and maybe pull the plug?

I like your thinking, but no. :slight_smile:
I don’t have one.

I suspect you’re running into this…

http://documentation.xojo.com/api/code_execution/end.htmlException

Confusing.
So calling Quit actually generates an exception deliberately?
And I need to re-raise it?

Which will then go into my unhandled exception handler… what should that do with it?

(Still never happens on my machine, by the way)

No, you don’t have to re-raise QuitException. Normally, you don’t see either QuitException or ThreadEndException.

If your unhandled exception handler you should have

if theError isA EndException or theError isA ThreadEndException then 'nothing to do Raise theError

Both open and quit of an app are a bit special. For open some things may not yet be there. For quit something may not be available anymore. Is it possible that the check for keyboard.AsyncAltKey isn’t a good idea for quitting?