Assertions do have a value in developing software with less bugs.

http://en.wikipedia.org/wiki/Assertion_(computing)

However, in a recent discussion between me and Tim, we Tim argued that assertions are to be avoided whereever possible because if an assertion fails, it often does abort the program (depending on various factors), which can lead to data loss, because of unsaved data.

Thus here is a suggestion on how to deal with that instead:

Old code (taken from bse/bseresampler.cc):

    if (frame != m_pcm_frame)
      {
        int64 l = read_frame (frame);
        if (l < 0)
          return l;
      }
    g_assert (m_pcm_frame == frame);

New code:

    if (frame != m_pcm_frame)
      {
        int64 l = read_frame (frame);
        if (l < 0)
          return l;
      }
    rapicorn_warn_if_fail (m_pcm_frame == frame);

The new macro rapicorn_warn_if_fail would check the condition and print out the source file and line when the condition fails, along with the condition itself, so that the programmer can debug the program.

That way, for the (unlikely) case that something goes wrong with the assertion the program would still continue to run, which would allow the user to at least save his data, instead of watching the program crash. This is desirable in the case of for instance using the resampling datahandle in a GUI application like the planned bsewavetool GUI.

Note that in this particular case, the bsewavetool commandline interface could produce incorrectly upsampled output data with the new code in place (which could happen without anybody noticing it in case of scripts processing files automatically), where it would abort with the old code in place. So we're making a different tradeoff with the change in place.

Just as with g_assert(), an extra version for the g_assert_not_reached() should be present, called rapicorn_assert_not_reached().