如果make_shared / make_unique可以抛出bad_alloc，为什么不尝试使用try catch块呢？

Question

make_shared的CppReference页面说（与make_unique相同）

可能引发std :: bad_alloc或T的构造函数引发的任何异常。如果引发异常，则这些函数无效。

这意味着在失败的情况下可以引发std :: bad_alloc接收。“函数无效”暗含意味着它无法返回nullptr。如果是这种情况，为什么不总是将make_shared / make_unique始终写入try catch块中是一种惯例？

使用make_shared的正确方法是什么？在尝试捕获块内？或检查nullptr？

Answer 1

我看到两个主要原因。

1. 动态内存分配失败通常被认为是不允许妥善处理的情况。该程序已终止，仅此而已。这意味着我们经常不检查所有可能的问题std::bad_alloc。还是std::vector::push_back因为底层的分配器可能抛出异常而将其包装为try-catch块？

2. 并非所有可能的异常都必须在立即调用方立即捕获。有建议认为throwto 的关系catch应比1大得多。这意味着您可以在更高级别上捕获异常，将多个错误路径“收集”到一个处理程序中。T构造函数抛出的情况也可以用这种方式处理。毕竟，例外是例外。如果在堆对象的结构是如此的容易丢，你必须检查每一个这样的调用，您应该考虑使用不同的错误处理方案（std::optional，std::expected等等）。

无论如何，检查nullptr绝对不是确保std::make_unique成功的正确方法。它从不返回nullptr-成功或抛出。