Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move standardized error codes out of ::openlcb:: #411

Open
balazsracz opened this issue Aug 2, 2020 · 2 comments
Open

Move standardized error codes out of ::openlcb:: #411

balazsracz opened this issue Aug 2, 2020 · 2 comments
Labels

Comments

@balazsracz
Copy link
Collaborator

Currently the only useful error enumeration in OpenMRN lives inside the openlcb::Defs class. This means that any openmrn component that needs to return errors is facing two unpleasant choices:

  • either depend on openlcb namespace to use a common error codes structure
  • or create a new, incompatible error enumeration which is the confusing and impossible to pass around in the call stack.

We need to discuss what would be a good way out of this. A requirement is that our error codes remain harmonized to the OpenLCB standard, i.e., the actual values should not change and be used by the ::openlcb:: namespace components as well. A desirable property is to have the ability to project any openmrn error code to an openlcb error code for transmitting through the network.

@balazsracz
Copy link
Collaborator Author

Probably the minimum acceptable solution here is to move the error enum into its own file under util/ErrorCodes.hxx and out of the openlcb namespace.

As some more advanced topic, we should look at encoding two things in the upper 16 bits of the error code:
1 - if this error code is openlcb compatible
2 - which component generated this error code, so as to allow looking up definition and comments in that specific components' documentation.

@bakerstu
Copy link
Owner

bakerstu commented Aug 2, 2020

I like these suggestions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants