Question

当我处理与数据库相关的操作时，我总是使用try catch。

try
{
 DataContext.AddtoObjectname(obj);
 DataContext.SaveChanges();
}
catch(Exception e)
{
 throw new Exception("Problems adding object" + e);
}

但我在这里读到了影响性能的尝试/捕获 -
Do try/catch blocks hurt performance when exceptions are not thrown?
所以我应该为我上面做的事情添加try catch，或者我应该选择其他方式。谢谢你的帮助。

Answer 1

Try / Catch语句本身不会显着影响性能，但抛出和捕获大量异常可能会。

通常，您希望确保仅捕获相关的异常 - 否则您可能会屏蔽应用程序中的错误。在这种情况下，DataException或UpdateException可能是很好的候选者，因为如果SaveChanges出现问题，它们将被抛出异常。

您似乎正在捕获异常以向其添加自己的附加信息。在这种情况下，最好将原始异常保留为内部异常。

throw new Exception("Problems adding object" + e, e);

我还建议为此目的创建自己的特定于应用程序的异常类型。

Answer 2

这取决于。如果你只打算重新抛出异常，那么在try catch中就没有意义了。您正在添加代码而不提供任何实际价值。如果您要对异常执行某些操作，请记录它，检查特定类型等，这是不同的，因为您打算对意外行为采取行动。

但我读到了关于try / catch影响的内容性能..

尝试catch并不是真正影响性能的因素，它创建了“昂贵”操作的异常。真的在大范围的事情中并没有那么糟糕，你不应该因为“费用”而避免例外。

在相关的说明中，如果你尝试捕获，除非你不需要创建一个新的异常，如果你可以避免它。只需重新抛出旧的异常。

Answer 3

只抓住你能处理的东西。如果您无法处理错误并正常恢复，请将异常冒泡到可以处理它的更高级别。如果你想记录发生的异常（合理），那么记录它并在你无法恢复的情况下重新抛出相同的异常。
作为一般规则，永远不要捕获一般异常。相反，明确指定例外：catch (SQLException e)而不是catch (Exception e)
如果从catch块中抛出异常，请确保将捕获的异常放入新的异常中。
不要抛出Exception，更具体一点。如果框架尚未满足您的需求，请制作一个。

Answer 4

是的，这就是try / catch for。失去控制并且有使数据库处于不一致状态的风险比尝试/捕获开销更高。如果有例外，一般来说没有“便宜”的方式来处理......