Re: [Qemu-devel] Coding style for errors

[Markus Armbruster <armbru@redhat.com>]

Lluís Vilanova <vilanova@ac.upc.edu> writes:

> Hi,
>
> I was wondering what is the proper way (or ways, depending on the subsystem) of
> reporting and signalling errors in QEMU. The coding style file does not seem to
> mention it, and the code uses all kinds of forms for that:
>
> * printf + exit(1)
> * fprintf(stderr) + exit(1)
> * error_report + exit(1)
> * cpu_abort
> * Some other I probably forgot

cpu_abort() and hw_error() are fancy ways to abort().  Terminating with
abort() on "this can't be happening" conditions is perfectly sensible,
and doing it in fancy ways can be useful.  For other errors, it's
inappropriate.

qemu/error-report.h is for reporting errors to the user.  Why not simply
fprintf(stderr, ...)?  Several reasons:

* error_report() & friends report errors in a uniform format.

* They do the right thing inside monitor commands: report the error to
  the monitor instead of stderr.

* They can add location information.

* They can add timestamps (-msg timestamp=on).

* If we ever do proper logging, they'll log the error.

There are many places left that fprintf().  Please don't add more.

qapi/error.h is for propagating errors up the call chain.  At some
point, you'll either recover and throw away the error, or you report it.
Convenience function error_report_err() makes that easy, but it's really
just a thin wrapper around error_report().

Another convenience feature makes reporting *fatal* errors easy:
&error_fatal.  Likewise, for programming errors: &error_abort.

When a simpler method for reporting success/failure to the caller
suffices, it's perfectly fine to use it.  E.g. returning a valid pointer
on success and null pointer on failure, or non-negative integer on
success and negative errno code on failure.

> So, is there any agreement on what should be used? If so, could that please be
> added to CODING_STYLE?

I think HACKING would be a better fit.