I would be tempted to have the compiler emit "foreach_<api-filename>_api_error" macros [or similar]:
#define foreach_foo_api_error \ _(SUCCESS, "Success") \ _(ERROR, "This didn't go well") To minimize pain in upgrading existing C-code... D. -----Original Message----- From: Ole Troan [mailto:otr...@employees.org] Sent: Tuesday, January 23, 2018 5:41 AM To: Dave Barach (dbarach) <dbar...@cisco.com>; Jon Loeliger <j...@netgate.com> Cc: vpp-dev <vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] RFC: Error Codes Dave, Jon, > On 22 Jan 2018, at 19:34, Dave Barach (dbarach) <dbar...@cisco.com> wrote: > > Dear Jon, > > That makes sense to me. Hopefully Ole will comment with respect to > adding statements of the form > > error { FOO_NOT_AVAILABLE, “Resource ‘foo’ is not available } ; > > to the new Python PLY-based API generator. > > The simple technique used to allocate plugin message-ID’s seems to work OK to > solve the analogous problem here. That makes sense to me too (wonder why we haven't done that before. ;-)) Here is the patch to the compiler: https://gerrit.fd.io/r/10204 VPPAPIGEN: Error definitions VPPAPIGEN: Error definitions This commit adds support for defining errors. errors { SUCCESS, "No error"; ERROR, "This didn't go well"; }; Which results in the following C: vl_error(VL_API_ERROR_SUCCESS, "No error") vl_error(VL_API_ERROR_ERROR, "This didn't go well") And JSON: "errors": [ [ "SUCCESS", "No error" ], [ "ERROR", "This is wrong" ] ] Does that seem sane? Cheers, Ole > > Thanks… Dave > > From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] > On Behalf Of Jon Loeliger > Sent: Monday, January 22, 2018 12:13 PM > To: vpp-dev <vpp-dev@lists.fd.io> > Subject: [vpp-dev] RFC: Error Codes > > Hey VPP Aficionados, > > I would like to make a proposal for a new way to introduce error codes > into the VPP code base. The two main motivations for the proposal are > > 1) to improve the over-all error messages coupled to their API > calls, and > 2) to clearly delineate the errors for VNET from those of various plugins. > > Recently, it was pointed out to me that the errors for the various > plugins should not introduce new, plugin-specific errors into the main > VNET list of errors (src/vnet/api_errno.h) on the basis that plugins > shouldn't clutter VNET, should be more self-sustaining, and should stand > alone. > > Without a set of generic error codes that can be used by the various > plugins, there would then be no error codes as viable return values > from the API calls defined by plugins. > > So here is my proposal: > > - Extend the API definition files to allow the definition of error > messages > and codes specific to VNET, or to a plugin. > > - Each plugin registers its error codes with a main registry upon being > loaded. > > - The global error table is maintained, perhaps much like API enums today. > > - Each API call then has a guaranteed set of return values defined > directly > within its own API definition, thus coupling API calls and their > possible > returned error codes as well. > > Other thoughts? > > Thanks, > jdl > > _______________________________________________ > vpp-dev mailing list > vpp-dev@lists.fd.io > https://lists.fd.io/mailman/listinfo/vpp-dev _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
