Should database insertions, updates and deletions be wrapped in try/catch?
在处理数据库相关操作时，我总是使用try-catch。
1 2 3 4 5 6 7 8 9 | try { DataContext.AddtoObjectname(obj); DataContext.SaveChanges(); } catch(Exception e) { throw new Exception("Problems adding object" + e); } |
但我在这里读到了影响性能的尝试/捕获-当不抛出异常时，try/catch块是否会损害性能？所以我应该为我正在做的事情添加"尝试捕获"还是选择其他方式。谢谢你的帮助。
Try/Catch语句本身不会显著影响性能，但抛出和捕获许多异常可能会影响性能。
一般来说，您希望确保只捕获相关的异常，否则可能会掩盖应用程序中的错误。在这种情况下，dataException或updateException可能是很好的候选者，因为它们是在saveChanges中发生错误时将引发的异常。
似乎您正在捕获一个例外，以便向它添加您自己的附加信息。在这种情况下，最好将原始异常保留为内部异常。
1 |
我还建议为此目的创建您自己的特定于应用程序的异常类型。
只有抓住你能处理的。如果您不能处理错误并优雅地恢复，那么就让异常冒泡到可以处理它的更高级别。如果您想将异常记录到它发生的地方(合理)，那么记录它，如果您无法恢复，则重新抛出相同的异常。
作为一般规则，永远不要捕获一般异常。相反，明确说明例外情况：
catch (SQLException e) 而不是catch (Exception e) 。如果从catch块抛出异常，请确保将捕获的异常放入新异常的内部异常中。
不要扔东西，具体点。如果框架还没有您所需要的异常，那么就做一个。
这要看情况而定。如果您只打算重新抛出异常，那么在try-catch中没有任何意义。您添加代码时没有提供任何实际值。如果您要做异常的事情，记录它，检查特定的类型等，这是不同的，因为您打算对意外的行为采取行动。
But I read about try/catch affecting
performance..
Try-Catch并不是真正影响性能的因素，它创建的异常是"昂贵的"操作。事实上，在大范围的事情上，这并不是那么糟糕，你不应该因为"花费"而避免例外。
在相关的注释中，如果您执行了一个try-catch，除非您不需要创建一个新的异常，如果您可以避免它。只是重新抛出旧的异常。
是的，这就是尝试/捕获的目的。失去控制并有使数据库处于不一致状态的风险比尝试/捕获开销更高。如果有例外，一般来说，没有"便宜"的方法来处理……