在明显需要的位置（例如获取特定用户输入）之外，Try/Catch 的约定是什么？虽然代码重用是 OOP 背后的一个重要思想，但是否期望每个（示例）数组访问都应该有一个 try/catch？是否主要是设计者决定什么可以引发异常，以及程序的那些部分应该受到足够好的监管以从不引发异常？
例如。一系列扑克牌是并且应该永远是 52 张牌。不需要尝试/捕获。 或者由于数组越界异常可能会导致运行时错误，并且该牌组可以在以后添加百搭牌后使用，那么现在就将其放入？
【问题讨论】：
标签： c# coding-style error-handling try-catch
您应该只捕获异常，您可以实际处理。 IE。你不应该到处都有 try/catch 语句。
至于抛出异常，你应该在没有更好的选择时抛出异常。如果您可以有意义地处理用户输入，那么在这种情况下没有理由抛出异常。在不知道具体情况的情况下，我会假设在这种情况下不需要例外。
【讨论】：
你的例子有点不对。
假设您有一个包含 52 个元素的数组，处理此问题的正确方法是在尝试访问它之前测试您的索引是否在数组的范围内。这比简单地将代码包装在 try .. catch 中要好得多。
Try Catch 可以帮助我们摆脱自我。如果给定的方法编码正确，那么几乎没有理由使用它们。正确地说，我的意思是您验证您的输入是否在预期的范围内，并且您已经进行了足够的测试以知道代码不会“排除”出来。当然，“很少”的一个例子包括对非托管资源的调用，例如 SqlConnection 对象。
关键是，它是最后的努力，可以从特定代码块的执行中挽救可用的东西。
但是，如果确实对异常无能为力，那么我会说您唯一的选择是忽略它并让它冒泡或捕获、记录并重新抛出。
【讨论】：
Trey Nash 在他的 Accelerated C# 一书中建议（可能大多数人都这样做）以一种否定使用 try/catch 分支的方式进行编程。您看到的大多数尝试/捕获都可以通过更好的编程来消除。在某些情况下，您需要它，主要是处理文件句柄、数据库连接，基本上任何时候您需要使用带有实现 IDisposable 的类型的 using 语句（其背后是 try/finaly 块）。任何在操作系统中使用超出您控制范围的东西可能会出错，请使用 try catch。
并且尽量不要使用通用
try { //some exception thrown }
catch (Exception ex) { }
这太笼统了，尽量处理可能发生的更相关的异常，而不是让它们都进入一般的 catch 语句。
【讨论】：
一般来说，我倾向于捕获异常、记录它们、重新抛出，然后最终进行一些应用程序级别的异常处理，从而向用户呈现一般错误。
在特定情况下，您可能知道是什么导致了异常（例如，您捕获了一个异常，表明与数据库服务器的连接已断开），您可以捕获特定异常，然后为用户生成适当的错误消息。
如果无效的用户输入导致异常，那么您的代码有错误，您需要验证您的输入。
【讨论】：
您应该避免使用 try/catch，因为它非常昂贵。在大多数情况下，您可以实施必要的检查以避免抛出异常。
关于集合或数组，您可以检查集合中有多少项以避免错误。
使用 try catch 的有效位置是读取文件或访问 3rd 方资源时。
当您捕获异常时，记录它并尝试找到避免它的方法。
当重新抛出异常时，使用下面的代码 尝试 {
}
catch (Exception ex)
{
throw;
}
希望能回答你的问题。
【讨论】：
Try/Catch 自己说，你试图做某事，发生了某事（在我们的例子中不是一件好事）并且你试图抓住例外使用该信息做某事。
道德：如果您知道可能存在异常，并且如果您知道发生异常时您会做什么，请使用try/catch 来开发您的异常处理逻辑。
如果没有，则try/finally 更有意义（例如在IO 访问期间为分配的资源处理逻辑执行保证）。
希望这会有所帮助。
【讨论】：