在开发过程中，我们经常需要处理错误和异常。但是，我们不必在每个可能发生错误的地方都编写try-catch块。实际上，我们应该根据不同的层次和需求来决定在哪里以及应该编写多少try-catch块。

在UI层，我们通常会在Application_Error中捕获全局错误，并相应地进行处理。这样做的好处是，我们只需要在不希望错误传播到UI层并导致重定向到通用错误页面的情况下，才需要编写try-catch块。这种方法在报告大多数错误时非常有效。

有些人则会在业务层捕获错误，并从BLL中记录并返回它们，或者记录并重新抛出通用错误。例如，可以查看Enterprise Library异常块如何处理错误。

还可以使用AOP库（如PostSharp）来附加到要处理错误的所有对象上，或者使用MVC的异常过滤器来处理错误。

在编写try-catch块时，我们需要根据具体情况做出适当的决策。如果错误不会对应用程序的正常运行产生重大影响，并且可以在日志中记录并忽略它们，那么我们可能不需要编写try-catch块。相反，如果错误可能导致应用程序崩溃或无法正常工作，我们就应该编写try-catch块来捕获并处理这些错误。

我们应该根据错误的严重程度和对应用程序的影响程度来决定在哪里以及应该编写多少try-catch块。通过合理地处理错误和异常，我们可以提高应用程序的稳定性和可靠性。

我个人倾向于使用try-finally块比使用try-catch块更多（除了一些外部数据源调用）。

我将try-catch保留在代码的终点处，这样我可以记录错误堆栈，并在必要时处理错误消息。

顺便提一下，确保只调用throw;，以便不会吞没任何异常。

在编写代码时，我们常常需要考虑错误处理的问题。try-catch块是一种常见的错误处理机制，可以捕获并处理异常。然而，我们应该在哪些位置编写try-catch块以及应该编写多少个try-catch块呢？

有些人倾向于在代码的终点处编写try-catch块。这样做的好处是可以捕获整个代码块可能抛出的所有异常，并且可以在catch块中记录错误堆栈信息，并根据需要处理错误消息。这种做法适用于代码的最后一部分，因为在这里我们可以将所有异常捕获并集中处理。

另一方面，有些人更喜欢使用try-finally块而不是try-catch块。try-finally块通常用于确保资源的正确释放，例如关闭文件或数据库连接。在这种情况下，我们不需要捕获异常，只需在finally块中执行必要的清理操作即可。这种做法可以使代码更加简洁和可读性更高。

除了上述两种情况之外，我们还需要注意一些细节。当我们在catch块中捕获异常时，要确保只调用throw;，而不是不做任何操作或直接抛出新的异常。这样可以避免吞没异常，使得问题更加难以诊断和调试。

我们在编写代码时应该根据具体情况，在合适的位置编写try-catch块。对于整个代码块可能抛出的异常，可以在代码的终点处编写try-catch块以集中处理。对于资源释放等情况，可以使用try-finally块来确保正确的清理操作。在使用try-catch块时，要注意避免吞没异常的问题，确保只调用throw;。这样可以使我们的代码更加健壮和可靠。