Re: Error management in grl-plugin-registry APIs

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
do more work and could raise errors. In this case we can wait till
happens and change the API or we can prepare for that now already and
avoid API changes in the future.


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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]