Comment 1 by jteh on 2015-02-23 07:06
I understand the motivation behind this. However:

1. Users really shouldn't be tweaking config.conf themselves. If they do, they should either know what they're doing or be doing so under the explicit instruction of a developer. We need to gracefully handle errors in the UI, but we do not need to gracefully handle errors in stuff that uninformed users aren't supposed to touch.
2. Given 1), reverting to a default could actually be a bad thing because it masks the error and instead silently yields something that might be unexpected. For example, if an add-on author made such a mistake, they really need to know about it. If it just reverted to a default setting, they may never know until some confused soul finally realised that unexpected setting changes were being caused by that add-on. In short, trying to silently "guess" what the user/coder intended is rarely a good thing.
3. Transparently reverting to a default may also not be ideal where, for example, config needs to be upgraded. In that case, the code might need to know about the raw setting. That said, this is a fairly rare case that could be solved in other ways; e.g. a special method to get the raw value.

It'd be good if you can explain the real life motivation for this. Did some add-on do something like this recently?

I'll grant that if we're going to throw an error, it should be an explanatory one; StopIteration is not explanatory. For example, we report a useful error here:

>>> config.conf["braille"]["cursorBlinkRate"] = "f"

Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "config\__init__.pyc", line 1047, in __setitem__
  File "validate.pyc", line 602, in check
  File "validate.pyc", line 634, in _check_value
  File "validate.pyc", line 818, in is_integer
VdtTypeError: the value "f" is of the wrong type.

As you say, this too would require a list of possible values to validate against.

Comment 2 by nvdakor on 2015-02-23 07:47
Hi,
I came up with this while researching a way to allow code to catch an invalid entry for settings in combo boxes. There is a code that I'm looking into implement in one of my add-ons where a user is presented with a combo box, with the setting saved as a string. I figured that if the add-on will not deal with a string that is not in the list of options, it should present an error with the wrong setting and should revert to a default value, and thought this might be something that may exist in NVDA core, hence the scenario.
Another real-life situation might be if somehow nvda.ini is modified manually (via a text editor while NVDA is not running) and a user accidentally types extra characters (or deletes some or all characters) for a value stored as a string. If the user saves the config file, next time NVDA is run and if the dialog for that setting is opened, exceptions will be thrown and the dialog will not open, letting the user know (indirectly) that one or more settings had invalid entries.
Thanks.

cc @josephsl

@josephsl, I guess this is still the case. Right? Maybe it should be considered further while moving to Python 3.

Now that configobj 5.1.0 is integrated, maybe there are some features which would help to solve this.
cc: @feerrenrut

@josephsl is the issue still present?

With the (incomplete) example provided in the initial description, the error is not the same:

>>> config.conf['braille']['tetherTo'] = 'focused'
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "config\__init__.pyc", line 1242, in __setitem__
  File "configobj\validate.pyc", line 615, in check
  File "configobj\validate.pyc", line 647, in _check_value
  File "configobj\validate.pyc", line 1332, in is_option
configobj.validate.VdtValueError: the value "focused" is unacceptable.

Maybe because this parameter has changed in the config spec recently?

If the issue is still present, could you provide a representative recent example for clarity, as well as the expected result? Thanks.

Hi,

Try config.conf["keyboard"]["keyboardLayout"] = "classic". With this set, keyboard layout combo box value will not be selected from keyboard settings panel. This behavior, while not that great, is an improvement over iteration issue I reported almost nine years ago. Threfore, I think we can close this with a new issue to be created to deal with combo box value issue.

Thanks.