Core API: start using status codes?

[GPMueller]

It is not considered the best of code design, but since the API is in C, it may be a good idea to provide error codes as return values of all API functions. The codes could be converted to c-string messages with an additional API function. This would enable more use cases in UIs, for example displaying a corresponding message when a task could not be executed.

Example:

auto status = State_Setup();
if (status == SPIRIT_SUCCESSFUL)
{
    // ...
}
else
{
    std::string message = Code_to_Message(status);
    // display message in UI 
}

A question would be what to return: an int or a struct? Can a struct be wrapped appropriately in all important languages (python, javascript, julia, ...)?

OpenGL-like error checking would not be thread-safe...

[GPMueller]

Actually returning status codes on all API functions would be impractical, as there are quite a few functions which return e.g. an int.

It would therefore have to be an internal value or list in the State, which would not be thread-safe. Additionally, users of the API would have to wrap function calls to determine if an error occurred, which seems impractical.

[GPMueller]

The problems of balancing between return codes and exceptions is detailed quite well here: http://foonathan.net/blog/2017/12/04/exceptions-vs-expected.html I believe it makes sense to have a non-throwing API and throw exceptions for everything exceptional inside the core, but not otherwise. try/catch blocks should, however be more common in the core in order to be able to better backtrace exceptions.