Today, I again ran in a QASSERT(). The problem with an assert is that the software stops and voilà. Yes. The assert has a message telling me what happened (why it is asserting) and the location of the assert.

So I know it was a QList problem because of an out of range index. Good.

Only, to fix said problem, you need the location of the caller. Knowing that an assert was generated in qlist.h is hardly helpful.

Of course, most of you will say: just run your software in your debugger, then it will break when the assert happens. True, unless the assert happens in a child process you fork() from your main server that runs in the background. In that case, I am not too sure how easy it is to run said child in your debugger...

Snap! Websites has a powerful way to help programmers debug its library and plugins: When an error is thrown or a segmentation fault or similar processor error occurs, the library automatically spits out the current stack in stderr and in your log. That's powerful since that means you have a good 90% of the necessary information to fix the problem. In most cases, these 90% are enough to fix the problem without having to do any extra debugging. But that damn QASSERT() is in the way!

So? How could I palliate?

I actually wrote a new class that derives from the QStringList called snap_string_list. That class redefines that at() function and the [] operators. These overloaded versions check the index and if it is out of range, it throws. Voila! Now I can get the stack information I just mentioned and immediately find the exact location where the error occurs (well... more precisly, the exact function that generates the out of range error.) Once I replaced all the QStringList with snap_string_list objects, the error was located and fixed in no time.

If you run in a similar problem, you may want to make use of our class overload. Although the overload is not complete, you can very easily add other functions that you use and want to throw an exception.