Lets just repeat that for emphasis : Write all destructors as if they have an exception specification of throw(). Furthermore, assume all destructors behave as if they have an exception specification of throw(). A destructor that throws is always exception un-safe. You gain nothing from attempting to correct that behavior in client code.
However, delete CAN throw. In the case where delete throws, the destructor has already been called. Now, delete should only throw when you have corrupted the heap somehow, or aren't deleting a deletable object. All these cases are usually caught by the operating system as an access violation or seg fault, and represent a much more sinister bug.
When delete is called in a destructor, and that destructor is called as a result of stack unwinding while propogating an exception, and that call to delete throws an exception, there is nothing you can do anyway. When delete exits by throwing, while stack unwinding is already occuring, the result is a call to terminate.
In general, when you error while releasing a resource, theres not much you can do. Should you try and release it again? Probably not. It will just fail again. Usually, the best you can do is forget about it.
But there is certainly a benefit when the resource in question is something such as a socket or file handle. Failing to close a file handle is an error; but you should still try and clean up any other handles you have open.
Incidentally, the solution to your problem is just to not propogate the exception. If you fail to release the memory, theres nothing more you can do about that exception, so just forget it. Your code becomes
try { delete pointer;} catch (...) {}pointer = 0;
If delete throws, the memory is leaked. But it was going to leak anyway.