您不需要在try-catch中掩盖代码的每一部分。try-catch块的主要用途是错误处理和获取程序中的错误/异常。try-catch -的用法

您可以在想要处理异常的地方使用此块，或者简单地说编写的代码块可能抛出异常。 如果你想在对象使用后立即释放它们，你可以使用try-catch块。

我听到过的最好的建议是，您应该只在可以对异常条件采取措施的情况下捕获异常，而“捕获、记录和释放”并不是一个好策略(如果在库中偶尔不可避免的话)。

Herb Sutter在这里写过这个问题。绝对值得一读。 摘要:

"Writing exception-safe code is fundamentally about writing 'try' and 'catch' in the correct places." Discuss. Put bluntly, that statement reflects a fundamental misunderstanding of exception safety. Exceptions are just another form of error reporting, and we certainly know that writing error-safe code is not just about where to check return codes and handle error conditions. Actually, it turns out that exception safety is rarely about writing 'try' and 'catch' -- and the more rarely the better. Also, never forget that exception safety affects a piece of code's design; it is never just an afterthought that can be retrofitted with a few extra catch statements as if for seasoning.

方法应该只在能够以某种合理的方式处理异常时才捕获异常。

否则，将其向上传递，希望调用堆栈中更高位置的方法能够理解它。

正如其他人所注意到的，在调用堆栈的最高级别上使用一个未处理的异常处理程序(带有日志记录)是一种良好的实践，以确保记录任何致命错误。

正如在其他回答中所述，只有在可以对异常进行某种合理的错误处理时才应该捕获异常。

例如，在生成您的问题的问题中，提问者询问忽略从整数到字符串的lexical_cast异常是否安全。这样的阵容永远不会失败。如果它失败了，说明程序中出现了严重的错误。在这种情况下，你能做些什么来恢复呢?最好的方法可能是让程序死亡，因为它处于不可信任的状态。因此，不处理异常可能是最安全的做法。

我同意你的问题的基本方向，即在最低级别处理尽可能多的异常。

一些现有的回答是这样的:“您不需要处理异常。别人会在上面做的。”根据我的经验，这是一个不考虑当前开发的代码段异常处理的糟糕借口，让异常处理其他人或以后的问题。

在分布式开发中，这个问题会急剧增加，在分布式开发中，您可能需要调用由同事实现的方法。然后，您必须检查嵌套的方法调用链，以找出他/她为什么向您抛出一些异常，这在嵌套最深的方法中可以更容易地处理。