From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50915) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZowYz-0007Na-St for qemu-devel@nongnu.org; Wed, 21 Oct 2015 12:48:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZowYw-0002Al-NC for qemu-devel@nongnu.org; Wed, 21 Oct 2015 12:48:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20231) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZowYw-0002Ag-Hk for qemu-devel@nongnu.org; Wed, 21 Oct 2015 12:48:30 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 2744EC0AF7BB for ; Wed, 21 Oct 2015 16:48:30 +0000 (UTC) Received: from blackfin.pond.sub.org (ovpn-116-54.ams2.redhat.com [10.36.116.54]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9LGmSi2022763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 21 Oct 2015 12:48:29 -0400 From: Markus Armbruster References: <8737x4p8l9.fsf@fimbulvetr.bsc.es> Date: Wed, 21 Oct 2015 18:48:27 +0200 In-Reply-To: <8737x4p8l9.fsf@fimbulvetr.bsc.es> (=?utf-8?Q?=22Llu=C3=ADs?= Vilanova"'s message of "Wed, 21 Oct 2015 17:03:30 +0200") Message-ID: <87si54i2w4.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Coding style for errors List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Llu=C3=ADs Vilanova writes: > Hi, > > I was wondering what is the proper way (or ways, depending on the subsyst= em) of > reporting and signalling errors in QEMU. The coding style file does not s= eem 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=3Don). * 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 plea= se be > added to CODING_STYLE? I think HACKING would be a better fit.