Dear Dave, > 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...
Ah, yes of course. Done. https://gerrit.fd.io/r/#/c/10204/ Cheers, Ole > -----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 >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
