libelektra: Error Concept Improvements Metaissue
Summary of improvement TODOs from PR https://github.com/ElektraInitiative/libelektra/pull/2435
- Write guidelines how to categorize errors.
- Please put memory allocation errors in its own category so that they are easy to find in future.
- Reduce the size of kdberror.h by refactoring (https://github.com/ElektraInitiative/libelektra/pull/2435#discussion_r269786368)
- Possibly add a macro
ELEKTRA_ADD_SOLUTIONwhich can serve as new method of supplying a solution (https://github.com/ElektraInitiative/libelektra/pull/2435#discussion_r269769574) - Error code format changes for Warning/Errors (https://github.com/ElektraInitiative/libelektra/pull/2435#discussion_r269767654)
- Make a concept for the API (https://github.com/ElektraInitiative/libelektra/pull/2435#pullrequestreview-219722372)
- Errno should be handles by error framework
- Checker tool to see for unused errors/warnings (https://github.com/ElektraInitiative/libelektra/pull/2435#discussion_r267290712)
- Optimize the dynamic dispatching in the
kdberrors.hto notstrcmpfor the full code but for the first digits and then for the full string. This reduces thestrcmpcalls significantly if there are lots of error codes. This performance optimization though should be more relevant if we have much more error codes (currently only 8) (Idea from @kodebach ) - Differentiate the error by the name rather than by the parameter, eg.
ELEKTRA_ERROR_RESOURCE(...)instead ofELEKTRA_ERROR(RESOURCE,...). (https://github.com/ElektraInitiative/libelektra/pull/2589#discussion_r273174729) - Change the warning key structure to not be limited to 100 entries but instead use arrays (https://github.com/ElektraInitiative/libelektra/pull/2589#discussion_r272829754)
- Incorporate an
INFOlevel (https://github.com/ElektraInitiative/libelektra/issues/2610) - Add ElektraError accessor functions to highlevel API (@kodebach idea)
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 15 (9 by maintainers)
I agree, but it would be handy to be able to set the log level by configuration (without recompiling).
Edit: I also think that INFO is too verbose as a default setting.
I agree with both of you. There is no good concept for
infomessages in Elektra, but integrating them into the error concept is also not a good solution. The problem IMO is that logging in Elektra is disabled by default and even if Elektra is compiled with-DENABLE_LOGGER=ON, the logging is filtered very heavily (only message from files belowsrc/toolsare shown), unless you maintain a separate version oflog.c.IMO we should enable logging to syslog (I think we are missing openlog and closelog) by default for message of level INFO and above, no matter were the originate from.
This is basically abusing the error message concept to also use for logging. I have never seen anything like that in a project before. There should be another concept or way of logging and saving cache hit messages. I can add it here as idea but it would really be against my intuition to incorporate it into the error concept
As discussed in #2610 it would also make sense to have
infomessages which are not shown by default at all.