Error handling?

Plugin and library development
1

I recently filed an issue about a simple user error resulting in a SIGSEGV on a NULL pointer reference when the DISPLAY environment variable is not set.

I looked into the code, and this is from the function generating the NULL:

gst_gl_gbm_drm_fb_get_from_bo (struct gbm_bo *bo)
...
if (ret != 0) {
    GST_ERROR ("Failed to add GBM BO as scanout framebuffer: %s (%d)",
        g_strerror (errno), errno);
    g_free (fb);
    return NULL;
  }

And you see comments like this in functions calling the above function:

      GST_ERROR ("Could not set DRM CRTC: %s (%d)", g_strerror (errno), errno);
      gst_object_unref (context);
      /* XXX: it is not possible to communicate the error to the pipeline */
      return;

So there’s this repeated pattern of logging errors and returning, requiring every calling function to check it’s return values before use. This is very tedious, redundant, and error prone.

What’s the philosophy behind this limitation? When a SIGSEGV occurs, you get aborted anyways, so why not just intentionally abort instead of trying to heroically carry on?

2

There is not ‘philosophy’ behind this. Just a little bit of poor design. The other backends do not have this issue at all.
This can also be fixed with more code being able to propagate errors upwards towards the user so they can deal with it.