Error handling in C

[SanjoDeundiak]

Currently C libraries don't use asserts and every possible error is handled using function return values. This approach is very safe, but at the cost of convenience at both function implementation and caller-side. My suggestion is to create groups to which we can divide error cases, and decide whether we should use return values or asserts for each of them

[SanjoDeundiak]

I'll start with error cases that come up to my mind:

1. Memory allocation error
2. Memory free error
3. Checking object pointer (this) for null
4. Checking arguments for null pointers
5. Checking arguments for validity (except of null check)

[mrinalwadhwa]

Thank you for making that list, please keep adding to it as more items come to mind. I'll spend some time thinking about this as well.

[hollyfeld]

Lots of relevant info and discussion here.

https://interrupt.memfault.com/blog/asserts-in-embedded-systems

[mtm0183]

To throw something else in the mix:

There are definitely arguments to be made for using assert, but I think a lot of those arguments may only be valid when you're developing an entire system or library like an operating system where it maintains extremely low-level control. Ockam, however, is a library that will be used by other developers in their applications and not act as a controller for the entire system.

From Ockam's perspective, failing to allocate memory for required internal use will probably constitute a failure for the Ockam library, but it is highly possible Ockam is running as just one of many tasks/threads in a system. In the case of an embedded system, Ockam may not be that high of a priority compared to the other tasks performing more critical operations in the system. In that case if the Ockam library fails the system may want to log the failure and attempt to restart the library at a later point. If we opt to use asserts, we'd end up locking up whatever task/thread we're running in until the OS or the watchdog steps in.

By allowing us to pass critical errors back up to the callers of Ockam, it gives the developers the option to assert on failures, deinitialize/reinitialize Ockam as memory is freed or take other appropriate action. The key is we don't force the choice on them.

[SanjoDeundiak]

@mtm0183 good point. What about taking behaviour of standard libraries and compiler as a baseline? I just realised that alloc indeed doesn't fail if there is no available memory. But what about items 2-4 from the list above?
2. If you try to free invalid pointer, you'll get crash.
3. If you pass this = null to C++ method, AFAIK there is no checks, and you'll get segfault as soon as you try to access fields of the object.
4. Passing NULL as destination to memcpy will result in runtime error.

My another point would be that in case of using assertions in code, we can (more likely should) define our own assert macro, which could be more agile, for example crash in debug, but early quit from function in release, or let user customise assert's behaviour, we could even use different types of asserts in different places.

[mrinalwadhwa]

#244