try-catch每个数据库连接？

Question

是否建议在每个打开数据库连接的函数中放置一个try-catch块并在那里记录错误，或者我是否应该在应用程序的更高层中捕获错误？

public static Category GetCategoryByName(string name)
{
    Category result;
    try
    {
        using (IDbConnection conn = ConnectionHelper.CreateDbConnectionByName(_connectionStringName))
        {
            conn.Open();
            using (IDbCommand cmd = conn.CreateCommand())
            {
                //do stuff
            }
        }
    }
    catch(Exception e)
    {
         // log error here?
    }
    return result;
}

更确切地说

try
{
    Category myCat = DataTools.GetCategoryByName("myCat");
    // other stuff
}
catch(Exception e)
{
   // log error here?
}

总结一下：代码中应该尽早发现错误吗？ 或者我应该在有关上下文的更多信息的地方抓住它们？

Answer 1

一如既往，它取决于，但一般情况下，如果你可以做一些事情，或者你有特定的代码（例如重试）发生只捕获异常，否则，让异常冒泡，最顶层可以记录它/以集中的方式处理它。

任何其他方式都会导致大量日志记录代码散布在所有业务逻辑中。

Answer 2

捕获异常时，请始终尝试使用最准确的异常。 例如，在使用SQL Server时，请捕获SqlException，因为它将包含有关exceptin的更多信息，而不是一般的Exception。 您可以获得实际的行号和其他有用的诊断信息。

在提取并记录了所有相关的内容之后，重新抛出异常或将其包装在不太具体的异常中，例如InvalidDataException或Exception并抛出它。 然后，您可以在更高级别捕获这些更通用的异常。

try
{
    // Execute DB call here
}
catch(SqlException exp)
{
    // Log what you need from here.
    throw new InvalidOperationException("Data could not be read", exp);
}

从更高级别调用此方法时，您可以捕获InvalidOperationException。 如果更高级别确实需要更多细节，则InnerException将提供可以访问的SqlException。

我遵循的异常处理的一般方法是仅捕获我可以有用地执行的操作。 在较低级别的代码中捕获真正的一般异常是没有意义的，因为您可以真正期望一切都出错或者能够从每个异常中恢复，例如OutOfMemoryException或StackOverflowException。

Answer 3

我更喜欢第一种方法，但是你还需要弄清楚我还能做些什么来阻止...

• 重新抛出异常？
• 扔另一个（更普遍的）例外？
• 将null返回给调用者？

Answer 4

我通常只处理UI中的异常，下面的所有内容我总是把它扔回顶层。 这样，堆栈跟踪一直保持不变。 你总是可以记录并扔掉它。

我之前也用过这个：

try
{
   DB Command
}
catch (Exception ex)
{
   Log(ex)
   throw; //preserve stacktrace
}