error_handling.md

Error Handling

Problem

There are ambiguous cases where the same return value can refer to multiple problems:

• name modifications which can be either invalid name or locking the key name
• getting values of (non-)binary keys

Constraints

We also have to consider that many parts of the API very constrained in what values they can use for error codes. If a function returns a pointer the only possible error value by definition is NULL.

Assumptions

Considered Alternatives

• Change return types for many functions across the API

Decision

• Update documentation in doc/dev/error-* and link to them in the documentation for the module kdb
• Add second channel for getting information about errors
• Return error codes directly from functions where failures are expected, e.g. kdbGet, keySetName
• Harmonize return values from all functions and move error reporting to second channel

Rationale

This simplifies and unifies error reporting across all functions. It also introduces a default way for the developers to handle error reporting. Developers of bindings for Elektra can rely on the existing error reporting feature without having to introduce custom error messages, that can vary wildly between different bindings.

Implications

Related Decisions

• Binary metadata vs flag #4194

Notes