Re: Error management in grl-plugin-registry APIs

["Juan A." Suárez Romero <jasuarez igalia com>]

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?

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

	J.A.