如果make_shared/make_unique可以抛出bad_alloc，为什么它不是一个常见的做法有一个尝试捕捉块？

Question

make_shared的CppReference页面显示（与make_ unique相同）

可能会抛出std:：bad_alloc或T的构造函数抛出的任何异常。如果抛出异常，函数将无效。

这意味着在发生故障时可以抛出std:：bad_alloc exeception。“函数没有效果”隐含地意味着它不能返回null ptr。如果是这种情况，为什么将make_shared/make_ unique始终写入try-catch块不是常见的做法？

使用make_shared的正确方法是什么？在try-catch块内？或者检查nullptr？

Answer 1

抛出bad_alloc有两个效果：

• 它允许在调用方层次结构中的某个位置捕获和处理错误。
• 它产生明确定义的行为，无论是否发生这种处理。

这种明确定义的行为的默认方式是，通过调用< code>std::terminate()以快速但有序的方式终止进程。请注意，在调用< code>terminate()之前，堆栈是否展开是由实现定义的(但是，对于给定的实现，仍然是定义良好的)。

这与未处理的failed malloc()有很大不同，例如，后者(a)在取消引用返回的空指针时导致未定义的行为，以及(b)让执行轻松地进行，直到(并超越)那一刻，通常会在此过程中累积更多的分配失败。

接下来的问题是，调用代码应该在哪里以及如何捕获和处理异常。

在大多数情况下，答案是它不应该。

处理程序要做什么？实际上有两种选择：

• 以比默认未处理异常处理更有序的方式终止应用程序。
• 在其他地方释放一些内存并重试分配。

这两种方法都增加了系统的复杂性(尤其是后者)，这需要在特定的环境中证明是正确的——更重要的是，在其他可能的故障模式和缓解措施的背景下。(例如，已经包含非软件故障保护的关键系统最好快速终止，让这些机制发挥作用，而不是在软件中瞎折腾。)

在这两种情况下，在调用方层次结构的更高层次上进行任何实际处理都可能比在进行失败分配时更有意义。

如果这些方法都没有增加任何好处，那么最好的方法就是让默认的std：：terminate（）处理开始。

Answer 2

我认为有两个主要原因。

>

动态内存分配失败通常被认为是一种不允许优雅处理的情况。程序终止了，就这样。这意味着我们通常不会检查所有可能的＜code＞std:：bad_alloc＜/code＞。还是将＜code＞std：：vector：：push_back

并非每个可能的异常都必须在直接呼叫端捕获。有人建议投掷与接球的关系应比一大得多。这意味着您可以在更高级别捕获异常，将多个错误路径“收集”到一个处理程序中。T 构造函数引发的情况也可以这样处理。毕竟，例外是例外。如果堆上的对象构造非常可能引发，以至于您必须检查每个此类调用，则应考虑使用不同的错误处理方案（std：：optional，std：：expected等）。

无论如何，检查nullptr绝对不是确保std：：make_unique成功的正确html" target="_blank">方法。它永远不会返回 nullptr - 要么成功，要么抛出。