Pardon me if this question is too silly. The most common example of usefulness of using RAII is :
void func(){
// create some object pointer using any smart pointer
// do some operation that may throw
return;
}
// whether method returns from the *return* statement or because of any exception it is guaranteed that the memory will be released
This article says that (if I understood correctly), if runtime system knows that there is no exception handler that can catch an exception after being thrown it may skip calling the destructors of automatic objects.
There is also a proposed solution to that problem, namely use catch(..) in main.
Now my concern is if the proposed solution is not used, then there may be resource leak even after using RAII. And there are situation when the solution can not be applied ( like creating a library which will be used by others). In that case serious problem can occur like corrupting a file that contains valuable information.
Should we really be concerned about the problem? Or I am just missing something?
Re
“Should we really be concerned about the problem?”
it depends on the context.
If you’re using destructor breakpoints or logging in debugging, then you need the relevant destructor(s) to be called. Likewise if a destructor is saving crucial state for a "Bird of Phoenix" process re-instantiation after crash. And if possible it’s nice to have unneeded-for-recovery temporary files removed, not laying around after a crash.
On the other hand, since the solution is so utterly simple – a try-catch around some calling code, e.g. up in main – it’s not really a practical problem. It’s more of just a thing to be aware of. E.g., to not expect destructors to necessarily be executed in someone else’s code that’s crashing via an unhandled exception.