Re: About gsettings aborting on unkown schemas

[ecyrbe <ecyrbe gmail com>]

2011/5/27 Emmanuele Bassi <ebassi gmail com>

On 2011-05-27 at 18:17, ecyrbe wrote:
> > > Of course it is.  With this bug, programs crash where they other-
> > > wise could limp on.
> >
> > potentially eating away data? without schema you don't have a default to
> > fall back to for application preferences and for state. it might end up
> > deleting existing account data, for instance. or eating your files.
> >
>
>
> nope, what you don't seems to understand is that you don't let the calling
> program deal with it.

and how do you propose to deal with that? if you allow the application
code to run then *anything* can happen, by definition. what's to say
that an app developer or a plugin developer decides to still go on and
not write sensible code? or tested code: a missing schema is an
installation issue, and people barely test error paths.

this might be acceptable for application developers and their own code,
but this sort of carelessness in designing a platform API is simply
not acceptable.

This is not dconf decision to make, it's the developper one. this where we are disageeing.

> With this behavviour
> you now have to protect your code from crashing by checking everytime that
> the schemas (or even the key) exists.

no, because the schema *has* to exists. why would you want to protect
from an abort()? don't you use g_assert() to protect internal state? you
might certainly not do that, but gtk+ does in multiple places.

Because it can happen?
if you are using a plugin hierarchy you will want to protect yourself
from crashing the entire application because of a single plugin.

imagine an anjuta plugin that is badly installed and that uses gsettings.
Then only one plugin can make anjuta crash (imagine a dynamic loading plugin hierarchy)
So now how can Anjuta protect itself from crashing? there is no way but adding workaround code on the plugin...
But the right way to do it should be for Anjuta to recover from some exception mecanism.
But C has no exception mecanism, so you need to make one or let the developpers deal with the error themselves.

do you want
to have a callback for gracefully showing an error dialog?

this is not going to work for the plugin hierarchy i explained.

> No data is eaten if the calling application show a gracefull message and
> exit from itself.

you cannot guarantee that for every application, unless the library
itself shows that error dialog — an error dialog that will essentially
be useless for the user ("Schema not installed. Reinstall the
application"; well, what now?). GIO cannot show error dialogs, so it
does the next best thing: abort() with an error message meaningful for
the developer in the error log, which will be caught by the desktop-wide
system service for application crashes, and will send a bug report.

what we need is a way for the Shell and for applications to be able to
validate the existence of a schema for their plugins.

Yes we need a way to validate schema existence for ANY plugin hierarchy system.
You can't seriously ask that every plugin system in gnome applications to reinvent this feature. (Gedit, Anjuta,Evolution, Gnome-shell etc)
 you have to provide a way to allow them to deal with the error. And the simplest one is to not abort,
 but if you have another suggestion, i'm all ears open.