libelektra: Error handling and return codes for errors are inconsistent across the public API
Currently, a lot of functions return the error value, regardless of error. These poses some problems, for instance authors of bindings, where it is hard to tell which error exactly occured. A big improvement to this would be returning different error codes for different types of errors, in order to be able to provide better information in cases of errors. Some functions also make use of an errorKey. While this seems like a decent approach, to provide additional informations in cases of error, it is currently very badly documented. It is not really transparent for the users of the function, what kind of information is included in the errorKey and even which messages could possibly be returned.
The first step would be to find an approach that is unified across all functions for error handling. This could mean changing the return types of every function to be more specific, or to include error keys into more functions. The second approach seems very impractical and would break basically the whole API. Changing return types would be a lot easier and more practicable. One can generally check for errors by returnValue < 0, and check for specific error cases via comparison.
Changing the return values of functions would also pose a good possibility of unifying return values for similar errors. So null pointers always return the same error code, read-only errors always return the same error code, etc. These error classes could also be implemented via an enum, which could in turn be documented. This would add a section to the documentation where all errors are documented in one single place.
Examples of function having “kitchen-sink” error codes:
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 1
- Comments: 18 (18 by maintainers)
Yes, I think it is a must-have.
The more detailed information can be provided by a link (inside or outside of Doxygen) but I think the basics about the errorKey must be directly in the API docu.