Questionable aspects of QEMU Error's design

[Markus Armbruster]

QEMU's Error was patterned after GLib's GError.  Differences include:

* &error_fatal, &error_abort for convenience

* Error can optionally store hints

* Pointlessly different names: error_prepend() vs. g_error_prefix() and
  so forth *shrug*

* Propagating errors

  Thanks to Vladimir, we'll soon have "auto propagation", which is less
  verbose and less error-prone.

* Accumulating errors

  error_propagate() permits it, g_propagate_error() does not[*].

  I believe this feature is used rarely.  Perhaps we'd be better off
  without it.  The problem is identifying its uses.  If I remember
  correctly, Vladimir struggled with that for his "auto propagation"
  work.

  Perhaps "auto propagation" will reduce the number of manual
  error_propagate() to the point where we can identify accumulations.
  Removing the feature would become feasible then.

* Distinguishing different errors

  Where Error has ErrorClass, GError has Gquark domain, gint code.  Use
  of ErrorClass other than ERROR_CLASS_GENERIC_ERROR is strongly
  discouraged.  When we need callers to distinguish errors, we return
  suitable error codes separately.

* Return value conventions

  Common: non-void functions return a distinct error value on failure
  when such a value can be defined.  Patterns:

  - Functions returning non-null pointers on success return null pointer
    on failure.

  - Functions returning non-negative integers on success return a
    negative error code on failure.

  Different: GLib discourages void functions, because these lead to
  awkward error checking code.  We have tons of them, and tons of
  awkward error checking code:

    Error *err = NULL;
    frobnicate(arg, &err);
    if (err) {
        ... recover ...
        error_propagate(errp, err);
    }

  instead of

    if (!frobnicate(arg, errp))
        ... recover ...
    }

  Can also lead to pointless creation of Error objects.

  I consider this a design mistake.  Can we still fix it?  We have more
  than 2000 void functions taking an Error ** parameter...

  Transforming code that receives and checks for errors with Coccinelle
  shouldn't be hard.  Transforming code that returns errors seems more
  difficult.  We need to transform explicit and implicit return to
  either return true or return false, depending on what we did to the
  @errp parameter on the way to the return.  Hmm.


[*] According to documentation; the code merely calls g_warning() then,
in typical GLib fashion.