ERS_STATIC_ASSERT
) those should be used to verity certain assertions at compile-time. For instance if you code rely on certain data structures having certain memory sizes, this can be checked using static assertions. ERS_PRECONDITION
) those should be used to check condition when entering functions. For instance if you only accept certain values for parameters precondtions should verify that those conditions are resepected. ERS_PRE_CHECK_PTR
) this special type of pre-condition checks that a pointer is valid (not null), you should this macro to check all pointers that a function or method receives as parameters. ERS_CHECK_PTR
) this type of checks is used to verify general pointers internally. ERS_ASSERT
) this macro can be used for checks that do not fit into any other category. N_DEBUG
is defined fprintf
like formatting ers::error
. The main difference between the different macros is that the Issue object they generate in case of violated condition contains different information fields. For instance all precondition macros generate issue that specify that the responsiblity for the Issue lies in the caller, not the callee. fprintf
like patterns. For each debug and warning severity_t level there is an associated macro: exit_value
method on the issue to possibly get an appropriate exit value (as defined in sysexits.h). A typical main program would look like this: int main(int argc, char** argv) { try { do_stuff(); } catch (ers::Issue &e) { ers::StreamFactory::dispatch(e); // we send the issue to the appropriate stream exit(e.exit_value()); // we get the actual exit value from the issue } // try / catch } // main