|There is nothing in the C++ standard that demands that this should generate a warning or error. The behaviour is well defined.|
Behavior is well defined and we know whether destructor will be implicitly noexcept or not by knowing the standard, but what we cannot know if whether we accidentally left throwing logic in destructor.
Consider a destructor which is implicitly noexcept(false), but you don't want this to happen, this is where those warnings come handy.
On another side consider a destructor which has no throwing logic but is implicity noexcept(false) not due to it's logic but due inheritance being poisoned, this is where the warning that you should put the noexcept keyword explicitly comes handy, because if you do so you'll get compile time error.
Problem however is that being explicit leads to yet another inheritance poisoning which is excactly my issue, I don't want to disable warning but I also don't want to poisoning, so my solution was to mark upmost class dtor noexcept(false).
But this now again problem because destructor may not throw as we already concluded.
|Note that noexcept was introduced with C++11. Before that a different way was used - and much of MS code was produced prior to C++11 being available...|
Yes I'm aware of this, with each new cpp standard come new static analysis rules but no updates to MS code.
Also a lot of MS headers still use dynamic throw() instead of noexcept, interesting how MS is forcing rules but does not update their own code.
In the end try\catch sounds like the only sane solution, then noexcept can be put and all warning gone.