Why can I get QT Libraries to throw ASSERT errors

[grabalon]

I have a bug that surfaces about once a day. This bug causes my application output to show the following:

ASSERT: "unindexedItems.isEmpty()" in file graphicsview\qgraphicsscenebsptreeindex.cpp, line 385
QWidget::repaint: Recursive repaint detected

I get no stack trace, and it is virtually impossible for me to recreate the error on purpose. I have found that I can set a breakpoint on qFatal() and will get access to the runtime stack that way before the application crashes, but it was my understanding that good programming practice was to put asserts only in places where you have control over input, and use them as a check to make sure that your input is good, while exceptions are more appropriate for libraries, because they are easier to handle without a disgraceful shutdown of the application.

Can anyone shed some light on either how I can more easily track down my bug, or why QT was designed with asserts, rather than exceptions?

Regards!

[SixDegrees]

If they're using the normal C ASSERT macro, you can define NDEBUG during compilation to eliminate the call to exit, which will likely lead to some other error that might get caught by the debugger. It's odd, though, that the debugger doesn't produce a stack trace, since ASSERT normally exits with status -1.

Otherwise, check your paint, repaint, update and associated drawing calls to make sure there's nothing suspicious going on there. There are warnings in the Qt documentation about potential recursive paint calls when some functions are used improperly.