[expr.new] p26 says

If any part of the object initialization described above terminates by throwing an exception and a suitable deallocation function can be found, the deallocation function is called to free the memory in which the object was being constructed, after which the exception continues to propagate in the context of the new-expression. If no unambiguous matching deallocation function can be found, propagating the exception does not cause the object's memory to be freed.

This implies that the deallocation function is unconditionally invoked as long as a matching version can be found. It didn't talk about whether or not a handler is necessary to be found before invoking that function.

Consider this example:

#include <iostream>
struct A{};
struct C{
    void* operator new(std::size_t N,A){
        std::cout<<"malloc\n";
        return malloc(N);
    }
    void operator delete(void* ptr,A){
        std::cout<<"abc\n";
        free(ptr);
    }
    C(){
      throw 0;
    }
};
int main(){
   auto ptr = new(A{}) C;
}

From this point, the invocation of the matching deallocation is observable, however, no implementations guarantee that function will be called. We can only find that [except.handle] p9 says:

If no matching handler is found, the function std​::​terminate is invoked; whether or not the stack is unwound before this invocation of std​::​terminate is implementation-defined

However, it is irrelevant here since stack unwinding only concerns destroying an object.

According to the implementations' behavior, we may add a condition for whether or not the matching deallocation function is called. Two suggestions here:

• If any part of the object initialization described above terminates by throwing an exception and a suitable matching deallocation function can be found, the deallocation function is called to free the memory in which the object was being constructed if a matching handler can be found([except.handle]), after which the exception continues to propagate in the context of the new-expression.

• If any part of the object initialization described above terminates by throwing an exception and a suitable matching deallocation function can be found, the deallocation function is called to free the memory in which the object was being constructed, after which the exception continues to propagate in the context of the new-expression. If no matching handler([except.handle]) is found, whether or not the deallocation function is called is implementation-defined.