GNOME Bugzilla – Bug 622554
g_error called if schema not installed
Last modified: 2011-06-04 19:19:22 UTC
If a schema is not installed GSettings fails with GLib-GIO-ERROR **: Settings schema 'org.gnome.gcalctool' is not installed and aborts the program. This is bad as the application has no way to fall back or indicate to the user that their application is improperly installed.
Similar critical error occurs if requested a key that is not in the schema: GLib-GIO-ERROR **: schema does not contain a key named '/apps/gcalctool/word-size'
Probably #2 will never be fixed. If you're operating in violation of your own schema, you have trouble... The only thing I might consider is an API to list all of the keys associated with a GSettings* since this has some introspection-type uses. For #1, I intend to add a g_settings_schema_exists() call.
ok. fixed both of these now. thanks.
You are in trouble if you violate the schema but the punishment is disproportionate. What if that key was only accessed in some obscure part of your program? All your saved unsaved work would be potentially lost and the application would have no chance of recovering. I really strongly recommend: - Writing loud errors to stderr if schemas/keys do not exist - Allowing g_settings_new() to return NULL. - Reading of an unknown key returning a default value (integer=0, boolean=false etc).
I second Robert on this, applications in the wild are not always written by experts and the user will rather see a load of error messages than losing his data. This is why I consider it wrong to happily abort in a library.
If the non expert can not even get schema installation right, why would you trust _any_ data to that application ?
(In reply to comment #6) > If the non expert can not even get schema installation right, why would you > trust _any_ data to that application ? Because there may be a rarely used key. Because keys added and removed don't disappear from the developer's cache. Those can happen even if the developer is not a complete idiot.
All that gives you is a critical warning and NULL return instead of crashing now (and getting a trace from where the error happened). There's no guarantee the app's 'rarely used' code paths will survive that NULL anyway. Also, IMO way too may people seem to think those critical warnings are just a nice warning, not the must-fix bug they are. That leads to them just persisting forever; e.g. take a look at the submitted ~/.xsession-errors files on launchpad — they're chock full of criticals even in stable releases and nobody ever fixes anything. What sort of errors will there be? - There could be simple typos in the schema or key names. That could be fixed by having the schema compiler generate a .h file containing #define's that include and then use the defines instead of literals, so you get these errors at compile time. - Type errors. Here, you should use the g_settings_get_<type> variants, and listen to your compiler warnings. - Anything else?
Other errors: - Filesystem corruption - Incorrect permission settings - Unmounted partitions - User edited files
(In reply to comment #9) > Other errors: > - Filesystem corruption Yes, if your filesystem is corrupted, things aren't going to work well. Just as easily, a library or the binary itself could be corrupted. > - Incorrect permission settings > - Unmounted partitions /usr/share/glib-2.0/schemas/ is never going to be not mounted, or not readable. > - User edited files If a user edits a binary file, they deserve to crash.
What about upgrades? A key that disappears during an upgrade could make an application crash. Of course you should save your important work before upgrading, but it’s better to let the application a chance to exit correctly.
The schema file is consulted when the application is first started and not loaded again after that.
(In reply to comment #12) > The schema file is consulted when the application is first started and not > loaded again after that. Fair enough. We’ll see as time passes use how it behaves, then. So far I never encountered a case where it would be a real problem.