Completion of error handling

[elfring]

Would you like to add more error handling for return values from functions like the following?

• malloc ⇒ ecs_array_new
• printf ⇒ load_admin

[SanderMertens]

Yes, definitely. Since I have your ear, I'd like to do a more comprehensive review of error handling. Today the API asserts when there is an error, and you get the file + line where the assert happened. Often that is sort of useful, but you don't really know where the error happened in your app code.

I'd like to move the actual assert to a macro that wraps the API, so that the assert reports the location in the application code, not in the library. That could make it much easier to debug things, as I don't need another tool to obtain the stack trace to see where it happened. Additionally, if you would use the "unwrapped" API, you'd have an API that never asserts, so you kind of have the best of both worlds.

Anyway, that's just an idea I thought would make life a little bit easer. Curious to hear what people think.

[elfring]

• I find the macro name “assert” suspicious for the mentioned use case.
• I suggest to reconsider the wrapping imaginations.

---

How do you think about to improve static source code analysis also for this software?

---

• Are you interested to apply aspect-oriented software development?
• Would you like to encapsulate error detection and corresponding exception handling as a reusable aspect in this software?

[SanderMertens]

@elfring Ok, I will reconsider that. For now, I will stick with the current approach, and address the issues you identified.

[SanderMertens]

I added a more complete description of error handling here: https://github.com/SanderMertens/flecs/blob/master/Manual.md