The question is, is this normal approach to handle exceptions inside destrucotrs? are there any examples that could make this design go wrong?
Yes, you can avoid throwing destructors like this if your // handle exception here code actually handles the exception. But in practice, if you are throwing an exception during destruction it usually implies that there is no good way to handle the exception.
Throwing from a destructor means that some sort of cleanup failed. Maybe a resource is leaked, data couldn't be saved and is now lost or some internal state couldn't be set or reverted. Whatever the cause if you could avoid or fix the problem you wouldn't have to throw in the first place.
Your solution to this bad situation (throwing destructor) only works when you aren't actually in the bad situation. In practice, if you try to apply this you will find that there isn't anything to write // handle exception here, except maybe warning the user or logging the problem.
if only one exception is allowed during stack unwinding?
There is no such rule. The problem with throwing during stack unwinding is if an uncaught exception escapes from a destructor. If the destructor throws and catches exceptions internally, it has no effect on ongoing stack unwindings. std::terminate explicitly states when stack unwinding ends in termination (link) :
In some situations exception handling must be abandoned for less subtle error handling techniques. These situations are:
[...]
-- when the destruction of an object during stack unwinding terminates by throwing an exception, or
[...]
