implement "robust" range-checks

[epruesse]

Currently, aw_assert fails in DEBUG mode and does nothing in NDEBUG mode.

I'd prefer to see warnings on the console in NDEBUG if the assertion can be "made to work".

For example, trying to use a negative "gc" should result in a warning in NDEBUG and just using "0".

[westram]

IMO an assertion is sth that is expected NOT to fail - ergo it cannot happen and there is no need to check sth in NDEBUG mode. That is also the way it has been used everywhere in ARB since its beginnings.

Another class of assertions are those that should not happen, but do often, e.g. because sth is not fixed. Normally code there looks like

void somefun() {
    arb_assert(cond);
    if (cond) {
        // real code
    }
}

It would be nice to have some macro to do that assert-if-combi, but i see no easy way use one.

What you describe above would be some kind of range-check and i would tend to implement it using sth like

<template typename T>
void arb_range_check(T var&, bool (*condition)(const T& t), T fallback) {
    if (!condition(var)) {
#ifdef NDEBUG
        // warn somehow
        var = fallback;
#else
        aw_assert(condition(var));
#endif
    }
}

That would not only be useful in WINDOW but throughout arb.

[epruesse]

Replying to westram:

Another class of assertions are those that should not happen, but do often, e.g. because sth is not fixed. Normally code there looks like

void somefun() {
    arb_assert(cond);
    if (cond) {
        // real code
    }
}

The ticket was inspired by the way GTK deals with applications trying to do things in the GUI that aren't possible. Like adding multiple children to a widget that can only hold one. While those things are in fact programming errors, they need not be fatal. So throughout GTK, preconditions are tested with macros that simply return from the function if they are not met (spewing error messages, but not terminating the program unless —g-fatal-warnings is provided on cmdline). In WINDOW, I use the same macros like so:

void AW_window::create_checkbox(const char* awar_name, bool inverse) {
    AW_awar* awar = get_root()->awar_no_error(awar_name);
    aw_return_if_fail(awar != NULL);
    ...
}

So if someone tries to create a checkbox for an AWAR that doesn't exist, create_checkbox complains and does nothing, but doesn't quit. The "aw_return_if_fail" macro also leaves the code looking neat. A series of them can be used at the beginning of the function to check that all preconditions are met. Subsequent code can then safely assume that they have been met.

That would not only be useful in WINDOW but throughout arb.

I agree. It's just that in the GUI in particular, failure is usually non fatal. I'd rather not draw something or launch something than exit the program.

[westram]

gtk-port is dead

[westram]

Ticket retargeted after milestone deleted