The ReconstructMe API is a pure C-based library. As such, it cannot make use of exceptions and exception handling, but must rely on transporting errors via error codes and similar instruments. Most the examples omit error handling for clearity. We catch up on this omission here.

Error codes

Every method in ReconstructMe API returns an error code of reme_error_t type. This enumeration type can be used to test the outcome of the last invocation. Here's a quick (and dirty) macro that simplifies this work.

// A simple macro that checks for any errors and exits if a method invocation failed.

#define OK(s) \

if (s != REME_ERROR_SUCCESS) { \

reme_context_print_errors(c); \

reme_context_destroy(&c); \

exit(-1); \

} \

Using this macro, we can test each method for success and exit if one returns without success.

Note however that not all possible states of reme_error_t represent an error that should cause your application to shut-down. Take for example REME_ERROR_TRACK_LOST, it indicates that the last attempt to determine the sensor position from the current sensor data did not succeed. In this case you should would wait the next frame and try again, instead of closing your application.

Error Checking at Critical Points

Instead of checking the return code each time, you can test for errors only at critical points in your application and get detailed access to error messages. The API provides you with methods such as reme_context_bind_error_info that reflects the current error message state.

Receiving Log Messages

ReconstructMe API supports logging callbacks to receive logging messages based on severity levels. Per reme_context_t one logging callback can be registered through the use of reme_context_set_log_callback. It allows you to pass a user_data parameter, that will be passed through to each invocation of the logging callback.