尝试/捕获性能

本文关键字：性能 尝试 | 更新日期: 2023-09-27 18:25:55

我需要读取不同类型的.txt文件，为此，我首先读取标题所在的前几行。有了这些信息，我可以选择读取它的方式。问题是，如果只有一条记录的格式不同（比如I substring(0,45)，并且只有40个字符），我的应用程序就会崩溃。我想避免这种情况，但我不能检查每一种可能性。我读到过，你应该避免使用太多的try/catch，而我只是在不知道错误可能来自哪里的时候才使用它。

我的问题是：在循环中使用try/catch（30k-40k次）不好吗？

如果不是，我该如何正确使用它？我不完全理解例外的目的。它们只用于调试吗？如果没有，throw new exception和MessageBox.Show("Error")之间有什么区别。

如果我不通知错误，只是跳过它，我可以写这样的东西吗：

try
{
//problematic code
}
catch
{
//nothing
//continue;
}

尝试/捕获性能

循环使用try/catch（30k-40k次）不好吗？

只有当你预计会有大量的例外情况时。如果不抛出异常，那么性能开销将非常小。

它们只用于调试吗？

没有，但主要用于在运行时查找错误（主要用于记录异常，以便您可以查看程序崩溃的位置/原因）。您无法预测所有事件，因此，一旦发生崩溃，您可以在适当的位置登录并进行咨询，这非常有帮助。

它们还允许恢复（如果您知道是什么导致了异常并知道如何处理）。其中一个例子是数据库事务死锁——当两个线程争夺相同的数据库资源时，其中一个线程将被选择终止（死锁受害者）——这只能通过异常捕获并通过重试事务来处理。

以下问题非常严重：

catch
{
//nothing
}

为什么？因为你最终忽略了你没有预料到的异常——你把它们扔掉，当你的程序最终崩溃或出现奇怪的错误时，你将不知道为什么。

但我不能检查所有可能的

是的，你可以！这是通常的做法。当设计一个复杂的函数时，希望考虑每一个案例。每一个没有考虑的案例都是一个潜在的bug。

你的尝试捕获隐藏了你没有想过的错误。您希望出现异常，以便注意到它们并解决潜在问题。

严格遵守所有nullref和indexoutofbounds异常始终是错误的约定。这最终为您节省了时间。

从性能的角度来看，当代码在try-catch块中运行时，与不在块中运行相比，性能会受到很小的影响。检查在没有抛出异常的情况下，try/catch块是否会影响性能？寻找差异的经验证据。

throw new exception和MessageBox.Show("Error")之间有什么区别？

对于初学者来说，异常是一个可以保存信息并被扩展以创建自己的自定义异常的对象，而MessageBox.Show()只是使用文本向用户显示。简而言之，一个是对象，而另一个是向用户显示信息的机制。不应将它们视为相互竞争的选择，而应将其视为补充。

最后，catch { //nothing }是一个可怕的想法，它相当于把头埋在沙子里以避免听到坏消息。永远不要这样做！

相关文章：