Using assert in main program logic of production code

Question

Suppose I have this in a custom Stack implementation:

void Pop (Stack & s) {
    assert (!isEmpty(s));
    // implementation details of popping omitted
}

Suppose I want to catch bad client uses like popping an empty stack. "Assert" is great until you compile the production version and disable it via the NDEBUG flag. What's the most professional way of dying gracefully if you detect an unrecoverable error, assuming that you are going to turn off assertions eventually?

Yes, I know there are a bunch of options: use "exit"; change the function to return a C-like error code; use C++ exception handling; just ignore the offending operation (make bad calls into a no-op); implement a personal version assert called something else that won't get turned off, etc.

What the "most pro" thing to do here? I just want to die quickly, with a helpful message.

For fun, I created a vector instance from the standard library and popped it empty. This caused a seg fault, which might be acceptable for the standard library, but I want to catch and report such a problem before dying.

Throw an exception. Probably [std::runtime_error](https://en.cppreference.com/w/cpp/error/runtime_error). However this question, is in my opinion, asking for an Opinion. — Richard Critten, Nov 14 '22 at 23:38
Does this answer your question? [Is using assert() in C++ bad practice?](https://stackoverflow.com/questions/12062365/is-using-assert-in-c-bad-practice) — Bob__, Nov 14 '22 at 23:47

score 0 · Answer 1 · answered Nov 15 '22 at 11:42

It is often used self defined assert macro with logging in production code. For example,

#define MYCOMPANY_ASSERT_FATAL(expression, msg, ret_val) if (!expression){ logger.fatal(msg); return ret_val;}
#define MYCOMPANY_ASSERT_WARN(...) .....
#define MYCOMPANY_ASSERT_ERROR(...) .....

Basically, the severity level of the error which should be regarded as exiting or messaging or so is dependent on your application program context layer. In short, some_lib_func() couldn't decide to exit an own process in most cases. That's why some_lib_func() should propagate the error information to caller. For example,

// library or middle module func couldn't decide to handle own application process, so after only logging return to caller 
bool read_csv(double& val) {
    double val = 0;
    bool ret = parse_csv_from_file(val);
    MYCOMPANY_ASSERT_ERROR(ret, "failed to parse_csv_from_file", false); 
    // return to caller with logging and error info(true/false here)
    ....
    ....
}

// application layer and need to handle for error which should be continue or message for user..
bool show_weather_in_foreign_country() {
    bool ret = read_csv();
    if (!ret) {
        show_error_message();
    }
    // in this case read_csv error is trivial and you want to continue to process with proper message
    ...
}

In this case, showing weather is considered as trivial process in your application and you don't want to exit a whole application if error, so after showing a appropriate message and continue to process. In the other hand, another case below is critical, despite using the same function of read_csv.

// application layer and need to handle for error which should be continue or message for user..
bool send_your_account_balance_in_securiities_to_your_wife() {
    double val = 0;
    bool ret = read_csv(val);
    MYCOMPANY_ASSERT_FATAL(ret, "critical in my account balance", false);
    // in this application context, the failure of read_csv is critical and never continue to process
    // and return to caller. Caller should probably exit an own application
    send_email_your_wife(val); 
    // if send 0$ with some kind of mistake to you wife, she might die or kill you ...
    ...
}

Therefore, preparing some of defined macro for propagating error and logging is so useful and make your code simple and safe, and then you need to use them properly depending on your application contexts.

Using assert in main program logic of production code

1 Answers1