我认为你的问题是你把“解决问题”等同于“让程序继续正确运行”。这是思考异常或错误处理的 * 错误 * 方式。
任何类型的错误处理代码都不应该是程序可以 * 内部修复 * 的代码。也就是说，错误处理逻辑（如捕获异常）不应该因为 * 编程 * 错误而被输入。
如果用户提供了一个不存在的文件名，这不是编程错误;这是一个用户错误。如果不返回到用户那里并获取一个现有文件，你就无法“修复”这个错误。但是例外情况确实允许你撤销你试图做的事情，将程序恢复到一个有效的状态，然后将发生的事情通知用户。
invalid_connection同样不是编程错误。与上面的例子不同，它也不一定是用户错误。它是预期可能发生的事情，不同的程序会以不同的方式处理它。一些程序会想再试一次。另一些程序会想暂停并让用户知道。
关键是，因为没有一种方法可以处理这种情况，所以库不能处理这种情况。必须将错误提供给库的调用者，以便确定如何处理。
如果你有一个解析整数的函数，而你得到的文本不符合整数，那么接下来该怎么做就不是这个函数的工作了。调用者需要被告知他们提供的字符串是错误的，应该做些什么。
调用方需要处理错误。
你不会因为一个应该包含整数的文件没有包含整数而中止大多数程序，但是你的解析函数确实需要把这个事实传达给调用者，而调用者也确实需要处理这种可能性。
这就是“捕捉异常”的作用。
现在，像OOM这样的意外环境条件就不同了。这通常不是外部代码的错误，但也通常不是编程错误。如果它 * 是 * 编程错误（即：P0709有一整节介绍了程序通常能够响应OOM的能力（或缺乏这种能力）。结果是，即使程序针对OOM异常进行了防御性编码，当它们用完内存时，它们通常 * 仍然会崩溃 *。
特别是在处理那些在实际使用页面之前不会将页面提交到内存的操作系统时。

这是我的看法，
捕获异常的原因还有很多，例如，如果是关键应用，如变电站等，捕获到的异常没有已知的系统恢复或解决方案，您可能希望有一个受控的关机，保护某些模块，保护连接的嵌入式系统等，而不是让系统自己崩溃。后者可能是灾难性的...
例如，你什么时候能够编写代码来修复通过异常发出的问题？当你得到一个std：：out_of_memory时，你应该怎么处理它？这不像你可以用操作系统来换取更多的内存。
事实上，我觉得这是我的主要编码风格有一段时间。我工作的一个系统没有大量的内存，而且系统是专用的，所以，它只是我的应用程序，没有其他任何东西。每当我遇到内存不足类型的异常时，我就杀死旧的进程，打开优先级更高的进程。当然，我会以一种受控的方式等待杀死发生。
考虑一个潜在的connection_error异常：你能做什么来修复这个问题，除了等待，稍后重试，并希望它修复自己？
我会尝试通过另一种介质连接，如蓝牙、光纤、总线等。通常情况下，当然会有一个主要的联系介质，除非有例外，否则不会调用其他介质。
但是，当一些库文档指出“如果此函数失败，将抛出internal_error异常”时，如果我不知道库内部是如何工作的，我怎么能够修复这个问题呢？
大多数情况下，专用库中的异常在系统中的后果与它本身的后果不同。您可能不需要阅读库及其内部工作来解决问题。您只需要研究它对软件的影响并处理这种情况。这可能是最简单的解决方案。如果库引发已知的异常，而不是崩溃或给出莫名其妙的答案，这将容易得多。

我想到的一个明显的问题是套接字连接。

• 您尝试连接到服务器A，但程序发现无法连接
• 尝试连接到服务器B

关于用户输入的其他示例即使不是更有效，也同样有效。
我承认看到一些东西

try
{
    connectToServerA();
}
catch(cantConnectToServer)
{
    connectToServerB();
}

在真实的代码中看起来有点奇怪。如果函数接受一个地址，我们遍历一个潜在地址列表，这可能是有意义的。
总的来说，我同意你的观点，你经常想做的就是记录错误并终止--但是一些系统，它们必须是健壮的和“永远在线”的，不应该在遇到问题时就终止。
Web服务器就是一个明显的例子。你不能因为一个用户的连接出错就终止，因为这会导致所有其他连接用户的会话中断。然而，在某些代码中，引发异常是处理这种故障的最简单的方法。