One of the things I've learnt from studying Microsoft code is to check everything outside yourself for indications of failure. in this case, every new should be followed by an is-valid check. The sooner after a failure, the better it is to understand the problem. I liken it to a railroad derailment: all of the train's twisted wreckage is not as interesting as the bad spot of track that goes bad at the very start of problems.Tulon wrote:2. When an out-of-memory situation happens inside the QImage class (part of Qt), it doesn't throw an exception, instead turning the image into a null image. That's very mean if you ask me. This means we would need to insert explicit checks every time we construct a QImage. That's currently done in some places but not in all of them. Fortunately, QImage is rarely used as is. Most of processing inside ST works with either imageproc::BinaryImage or imageproc::GrayImage classes that don't have this problem, even though GrayImage is a wrapper around QImage.
Have you considered an observer pattern? Exception-throwing threads can send bad news to someplace special. The someone in another thread who is expecting something from its exception-throwing threads can either register for notifications, or poll the bad news repository on a timeout.Tulon wrote:These were still good news, if you are wondering. The bad news is that ST is a multi-threaded application, making handling out-of-memory situations difficult. It's not a problem to catch the std::bad_alloc exception in a background thread. The real question is what to do next. You can't inform the user from a non-GUI thread and you can't just eat the exception, because the task that failed probably has someone in another thread expecting its completion.
I know this is superficial and does not reflect meaningful reflection upon the details you just provided. I've not yet gotten into your code so I let the best parts of what you said in the rest of your post fly over my head. I hope to apply deep thought to them when I'm less ignorant.