Lluís Vilanova <vilan...@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.
