From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40524) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SuPEw-0004X5-64 for qemu-devel@nongnu.org; Thu, 26 Jul 2012 10:40:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SuPEs-0006qi-5I for qemu-devel@nongnu.org; Thu, 26 Jul 2012 10:40:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43628) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SuPEr-0006qb-Rj for qemu-devel@nongnu.org; Thu, 26 Jul 2012 10:40:30 -0400 Message-ID: <501156D9.9020206@redhat.com> Date: Thu, 26 Jul 2012 16:40:25 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1343249431-9245-1-git-send-email-lcapitulino@redhat.com> <87boj3dyxg.fsf@codemonkey.ws> <501111CD.9000701@redhat.com> <87fw8eofto.fsf@codemonkey.ws> In-Reply-To: <87fw8eofto.fsf@codemonkey.ws> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 00/14]: add printf-like human msg to error_set() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: peter.maydell@linaro.org, armbru@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino , pbonzini@redhat.com, afaerber@suse.de Am 26.07.2012 14:41, schrieb Anthony Liguori: > Kevin Wolf writes: > >> Am 26.07.2012 04:43, schrieb Anthony Liguori: >>> Luiz Capitulino writes: >>> >>>> Basically, this series changes a call like: >>>> >>>> error_set(errp, QERR_DEVICE_NOT_FOUND, device); >>>> >>>> to: >>>> >>>> error_set(errp, QERR_DEVICE_NOT_FOUND, >>>> "Device 'device=%s' not found", device); >>>> >>>> In the first call, QERR_DEVICE_NOT_FOUND is a string containing a json dict: >>>> >>>> "{ 'class': 'DeviceNotFound', 'data': { 'device': %s } }" >>> >>> This is the wrong direction. Looking through the patch, this makes the >>> code much more redundant overall. You have dozens of calls that are >>> duplicating the same error message. This is not progress. >> >> I believe this is mostly because it's a mechanical conversion. Once this >> is done, we can change error messages to better fit the individual >> cases. > > We don't gain anything by touching every user of error and the code gets > more verbose. If we want to modify an existing error for some good > reason, we can do so my changing error types. We gain consistency instead of accumulating the relics of even more halfway completed direction changes. >>> We should just stick with a simple QERR_GENERIC and call it a day. >>> Let's not needlessly complicate existing code. >> >> Why even have error codes when everything should become QERR_GENERIC? Or >> am I misunderstanding? > > If we want to add an error code, we can do: > > error_set(QERR_GENERIC, "domain", "My free form text") > > And then yes, we can change this to: > > error_setf(errp, "domain", "My free form text") > > Or pick your favorite short name. You mentioned this domain thing before, and when asked you never explained what you really mean with it. Can you do so now, please? Assuming that it's just some error class string, I don't really see the difference between error_set(QERR_FOO, "Free form") as implemented by this series and error_set(QERR_GENERIC, "FOO", "Free form"). Kevin