[Cogl] [PATCH] Adds CoglError api

Neil Roberts neil at linux.intel.com
Mon Sep 3 06:08:04 PDT 2012


Robert Bragg <robert at sixbynine.org> writes:

> This patch also enforces a consistent policy for when NULL is passed as
> an error argument and an error is thrown. In this case we log the error
> and abort the application, instead of silently ignoring it.

I'm not sure whether this is a good idea. In GLib, if you pass NULL for
the GError argument it doesn't mean that you're not handling the error
but it instead means you don't care what the details of the error are.
It's the normal convention that functions that can throw a GError also
have some return value to indicate whether there was an error (such as
returning FALSE).

For example if you call cogl_pipeline_set_depth_state and you have a
fallback path for when the depth state isn't supported you can just
check the return value without looking into the GError. If you are doing
this every paint then it's quite nice to be able to avoid allocating the
GError just to redundantly free it again.

I think this behaviour is potentially more useful than aborting for most
of the errors that Cogl will throw and it's nice not to diverge from the
GError semantics unless there is a good reason.

Perhaps if we wanted to make the abort-on-error use case convenient then
we could add another dummy value to pass instead of NULL. For example,
_cogl_set_error and _cogl_propagate_error could detect when they are
passed COGL_ABORT_ON_ERROR. This could be defined to (void*)0x1 or
something.

Regards,
- Neil


More information about the Cogl mailing list