Design system for runtime logging and error handling

[erlingrj]

Currently we are adding a bunch of assert in the code. This is good, but they are only compiled when we are in CMAKE_BUILD_TYPE=Debug. Beside the assertions we want runtime error handling. E.g. we try to schedule an action too many times, or into the past or any other such error condition. Here we do not want to crash the program, but rather report it and continue executing.

This suggests that many functions should return a value, maybe an error type, maybe just an int. There must also be a way of setting an error string.

Finally, we also want to integrate with logging systems provided by e.g. Zephyr and RIOT. As such, we should make as few assumptions about underlying printf system as possible. We should study the alternatives available in Zephyr and RIOT before making design decisions.

[tanneberger]

I used enums for erros in my old implementation and I would recommend that we do that again.

[erlingrj]

I assume one big fat enum with all possible return codes? E.g. wait_until would need three different ones, SLEEP_COMPLETED, SLEEP_INTERRUPTED ERROR. Yes, we can add a:

typedef enum {
  UC_OK = 0,
  UC_ERR = 1,
  UC_SLEEP_INTERRUPTED = 2,
  UC_OUT_OF_BOUNDS = 3
  UC_INVALID_TIME = 4.
  UC_INVALID_VALUE = 5
  } uc_result_t

[tanneberger]

You suggest this enum for all user facing apis?

[erlingrj]

I think it could be nice with a single enum used on all functions that can fail instead of creating an enum for each case