在明显需要的位置之外(例如获取特定用户输入)，Try/Catch的约定是什么？虽然代码重用是OOP背后的一个重要概念，但是否期望每个(示例)数组访问都有一个try/catch？主要是由设计师决定什么可以引发异常，以及程序中那些应该受到足够好的管理以避免引发异常的部分吗？

一组扑克牌是，而且应该是，52张。不需要尝试/捕获。或者，由于数组越界异常可能导致运行时错误，并且可以在以后添加jokers时使用deck，然后立即将其放入？

您应该只捕获异常，实际上可以处理。也就是说，不应该到处都有try/catch语句。

至于抛出异常，当没有更好的选择时应该抛出异常。如果您可以有意义地处理用户输入，那么在这种情况下没有理由抛出异常。在不知道具体情况的情况下，我假设在这种情况下不需要例外。

你的例子有点离题。

假设您有一个由52个元素组成的数组，正确的处理方法是在尝试访问它之前测试您的索引是否在数组的边界内。这远比简单地用一次尝试来包装代码要好得多。抓住它。

"试着抓住"是为了帮助我们从我们自己身上拯救出来。如果一个给定的方法被正确地编码，那么就没有什么理由使用它们。正确地说，我的意思是您验证您的输入是否在预期的范围内，并且您已经进行了足够的测试，知道代码不会"例外"出。当然，"很少"的一个例子包括对非托管资源(如sqlconnection对象)的调用。

关键是，它是一根拐杖，是从特定的代码块执行中挽救有用的东西的最后努力。

然而，如果从字面上说，对于这个例外没有什么可以做的，那么我想说，你唯一的选择就是忽略它，让它冒泡，或者捕获，记录，然后再抛出。

TreyNash在他的书AcceleratedC中建议(像大多数人一样)以一种否定使用try/catch分支的方式编程。你看到的大多数尝试/捕获都可以通过更好的编程来完成。在某些情况下，您需要它，主要是处理文件句柄、数据库连接，基本上只要您需要使用一个实现IDisposable的类型的using语句(在封面后面是一个try/finally块)。在操作系统中使用任何超出您控制范围的东西，如果有可能出错，请使用一个try-catch。

尽量不要用将军

这太笼统了，尽量处理可能发生的更相关的异常，而不是让它们都进入一般的catch语句。

你应该避免使用Try/Catch，因为它非常昂贵。在大多数情况下，您可以实现必要的检查以避免抛出异常。

对于集合或数组，可以检查集合中有多少项以避免错误。

在读取文件或访问第三方资源时，将使用try catch的有效位置。

当您捕获异常时，请记录它并尝试找到避免它的方法。

再次引发异常时，请使用下面的代码尝试{

希望能回答你的问题。

一般来说，我倾向于捕获异常，记录它们，重新执行，然后最终进行一些应用程序级的异常处理，这会向用户显示一个一般性的错误。

在您可能知道导致异常的原因的特定情况下(例如，您捕获一个异常，该异常指示到数据库服务器的连接已断开)，您捕获特定的异常，然后为用户生成适当的错误消息。

如果无效的用户输入导致异常，那么您有错误代码，需要验证输入。

Try/Catch本身就说，你试图做一些事情，发生了一些事情(在我们的情况下，这不是好事)，你试图抓住这个例外，用这些信息做一些事情。

道义：如果你知道可能会有异常，并且你知道万一发生异常你会怎么做，那么使用Try/Catch来开发你的异常处理逻辑。

如果没有，则有更多的意义来使用try/finally(例如，在IO访问分配的资源时，处理逻辑执行保证)。

希望这有帮助。

我想我也会把这个扔进混合物里。埃里克·利珀特几年前发表了一篇关于这件事的优秀文章：

http://blogs.msdn.com/b/ericlippert/archive/2008/09/10/vexing-exceptions.aspx