Assertions vs if checks

Any program can have two classes of issues:

1. Runtime problems: situations programmer foresaw and handled; expected. E.g. invalid inputs, no access to resource, unreachable network, …
2. Bugs: programmer mistakes; unexpected. E.g. buffer overflow, access violation, …

There are different tools to deal with each; don’t conflate one with the other.

An assertion is just a validation of a programmer expectation; it “fires” when the expectation is betrayed.

(1) is familiar to most; use one of your language-provided feature including if, try-catch-throw, etc. that work at runtime. (2) needs early spotting of failing assumptions, changing invariants, unmet pre-/post-conditions at development-time¹.

int read_image(string path) {
  if !os.exists(path) {                // (1) runtime issue
    file_missing_dialog.show(path);
  }
  Image i = open_image(path);
  REQUIRE(i.resource_id != nullptr,    // (2) possible bug in open_image
          "Resource ID unassigned for opened image");
  cache(r.resource_id);
}

With asserts you’re checking your own code for possible bugs. In the above code we try to cache the most recently opened image with its resource ID; before doing so we make sure such an internal ID was properly assigned to the opened image with a REQUIRE macro. This check will be stripped from the final, released binary. It’d only exist in debug builds which developers and testers would use.

Though asserts are made of if statements, that’s true only for debug builds; they don’t fire on non-debug builds². C and C++ have a preprocessor stage, so most codebases define some assertion macro which compile to a no-op on non-debug builds and on a debug build – run by the developer or tester – define it as valid if; upon firing, an assertion helps the developer better understand the issue e.g. log a message, invoke the debugger³, etc.

#ifdef NDEBUG          // usually defined for non-debug builds
#  define REQUIRE(expr, msg) ((void) expr)            // no-op
#else
#  define REQUIRE(expr, msg) if (expr) {                     \
                               std::cerr << __FILE__ << ':'  \
                                         << __LINE__ << ": " \
                                         << msg;             \
                             }
#fi

You can have a variety of assertion macros like REQUIRE, DCHECK⁴, ASSERT, ENSURE, etc. to suit your needs and cases. check seems to be a minimal, header-only C library with basic assertions macros.

It’s a pointless wastage of CPU cycles, power, etc. to retain assertions in non-debug builds.

A software’s end-user seldom care/know about its technicalities⁵. Oblivious to its design and code, they can’t make sense of a failed assertion’s output — logs, running under debugger, etc. Contrastingly, programmers (and testers) specifically run debug builds just to catch a failing assumption early on. Stripping of assertions is one of the reasons⁶ why debug builds are slow and non-debug builds are fast — lesser if checks/branches.

Key difference is source: errors are due to the environment, user, etc. You simply have to check for them at runtime. However, assertions are to check your subsystems (module, function, component, etc.) for buggy code. This is when some expected state isn’t reached or some condition or invariant isn’t met. This is internal, within developer’s control. They can be avoided before the program hits the end-user by the programmer checking what broke the assumption.

Let’s say we’re developers of the popular media player VLC. Checking for a bad/corrupt input (avi/mkv file) should be done with a good ‘ol if that works at runtime.

However, whether VLC’s own source filter⁷ is always feeding normalized float data (within [0, 1]) to its decoding filter⁸ is something to be checked by an assert; checking this with a runtime if in Release builds would be a waste of end-user CPU’s time and energy.

Though a plain if also works as an assertion, a good programmer would use the right tool for the right job.