Re: About gsettings aborting on unkown schemas

[Shaun McCance <shaunm gnome org>]

On Fri, 2011-05-27 at 17:02 +0100, Emmanuele Bassi wrote:
> On 2011-05-27 at 10:57, Shaun McCance wrote:
> > On Fri, 2011-05-27 at 15:34 +0100, Emmanuele Bassi wrote:
> > > On 2011-05-27 at 14:59, ecyrbe wrote:
> > > > > and then what? abort the application? gracefully terminate with a
> > > > > warning on the console?
> > > > >
> > > > 
> > > > 
> > > > No, you can gracefully show a popup to the user that something is broken and
> > > > to the right direction. It's better than crashing.
> > > 
> > > and what would a popup solve from the user's perspective? a missing
> > > schema is a missing file, which means an installation problem. there is
> > > *no* graceful way to handle that.
> > 
> > If the application itself is missing files it needs (schemas,
> > ui files, .la files, whatever), then yeah. If it's some plugin
> > that's busted
> 
> how do you propose to define the difference between a plugin running in
> the application space and an application? from a library perspective,
> and from an application perspective, application + plugin and
> application are exactly the same thing.

If I were writing a native Python library, I would never
sys.exit on errors. I would always throw exceptions. The
library wouldn't distinguish between core and plugin, but
throwing exceptions allows the core to be written in such
a way that it can manage bad plugins.

Of course, GLib is not a native Python library. But when
underlying libraries do things like this, it makes it hard
for bindings to behave the way they should.

> > this is how I'd write my application code in a
> > language with real exception handling:
> > 
> > try:
> >     load_some_extension()
> > except:
> >     warn("This extension sucks. I'm disabling it and moving on.")
> 
> load_some_extension() *should* check if a schema exists in the current
> path, and raise an exception if not found. Ryan is working on being able
> to define custom search paths as well.

Then load_some_extension has to know the schemas that each
extension uses ahead of time, or it has to rely on each
plugin being good about checking its schemas. And the ui
files. And its data files. And $deity knows what else.

The point is to be able to write an application that can
continue to work in the presence of a piece-of-shit plugin.

(BTW, how does one check a schema? I don't see any API for that.)

> but once you reached g_settings_new() then there's nothing you can do
> because anything after that assumes that the GSettings returned exist
> and maps to a valid settings backend, with valid values.
> 
> > Of course, GLib is C. We don't have exceptions. We have GError,
> > which is a decent foundation for exceptions in language bindings.
> > But if we don't use it, then languages that could otherwise do
> > the right thing are screwed.
> 
> GError is for recoverable run-time errors, not for installation errors; a
> missing schema is an installation error.

So is a missing ui file, but gtk_ui_manager_add_ui_from_file
takes a GError**.

> by the way, GError, as it is implemented and used currently, is *not* an
> exception-like system. I'm not against creating a GException, but that's
> another thing, and the two should not be confused.

I don't even see how you could create an exception system in C,
short of adding a reference argument to every single function,
and rewriting everything to always check and propagate errors
after every function call. Not worth it.

Just make sure bindings can exercise their exception systems
correctly.

> we don't have g_malloc(size_t, GError**) for OOM cases as well, I just
> hope you're not honestly asking for that.

That would be overkill. And malloc failing is not an installation
problem. It's a your-system-can't-handle-this problem.

We do have g_try_malloc though, because in some situations, there
are actually things you can do. We don't have g_settings_try_new.

--
Shaun