-
-
Notifications
You must be signed in to change notification settings - Fork 630
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gracefully handle exceptions in UI Automation initialisation #483
Comments
Comment 1 by mdcurran on 2009-11-27 06:26 |
Comment 2 by jteh on 2009-11-27 06:29 |
Comment 3 by mdcurran on 2009-11-27 06:33 |
Comment 4 by jteh (in reply to comment 3) on 2009-11-27 06:36
Correct.
That's fine with me. However, the question then is: should we special case !NotImplementedError and not log an error in that case? (Perhaps log info or warning, but not an error.) So, the code would look something like:
|
Comment 5 by jteh on 2009-11-27 07:57 Fix implemented in r3390. |
Reported by jteh on 2009-11-27 05:49
A user reported that NVDA 2009.1 wouldn't start on his system. The log revealed that creating the UI Automation client object threw a "class not registered" error. While this is almost certainly due to brokenness on the system (maybe a broken install of the Platform Update?), UI Automation isn't essential and we can probably get away with just logging an error if it fails to initialise.
There are two ways we can do this (if we choose to do it at all):
UIAHandler.initialize()
and log them there; orUIAHandler.initialize()
incore.main()
and log the error there.Personally, I probaby prefer option 2, as initialisation really did fail, so core should know about it. Having said that, initialize() doesn't do anything special if UIA wasn't present, which makes this argument less valid.
The text was updated successfully, but these errors were encountered: