Re: Error management in grl-plugin-registry APIs

[Iago Toral <itoral igalia com>]

On Fri, 17 Dec 2010 16:30:18 +0100, "Juan A." Suárez Romero 
<jasuarez igalia com> wrote:
> On Fri, 2010-12-17 at 14:21 +0100, Iago Toral Quiroga wrote:
> > I see three situations:
> >   a) Functions that can fail for more than one reason. In this case 
> > a
> > GError parameter seems necessary.
> >   b) Functions that can fail for only one known reason. In this case 
> > a
> > gboolean return is enough, but adding the GError parameter would 
> > maybe
> > add some coherence to the API.
> >   c) Functions that cannot fail now, but we suspect in the future
> > could
> > do more work and could raise errors. In this case we can wait till
> > that
> > happens and change the API or we can prepare for that now already 
> > and
> > avoid API changes in the future.
> >
> > Opinions?
>
> IMHO I would add the GError to all those functions that semantically
> could fail, no matter if the fail can be due to different conditions
> (case a), always the same condition (case b), or even if with the
> current implementation they never, but it could if we change
> implementation (case c).
>
> So at least, for cases a and b, I would add the GError.
>
> For the case c, I would apply common sense for "semantically it can
> fail", because otherwise any function can fail :). Do we have a 
> function
> that could fit in case c?

Yes, grl_plugin_registry_register_source, it was in the list I shared.

> So for the cases you mentioned, I would add the GError, even in the 
> 7th
> case. I think this adds consistency to the API.

Ok, fine with me. I just pushed these changes.

Simón will be reviewing today how these should be handled on the 
introspection side (annotations) and will do appropriate updates to the 
python-test-ui too.

Iago