3

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

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

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

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

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

3 回答 3

3

但我无法检查所有可能性

是的你可以！这就是通常的做法。在设计复杂功能时，您需要考虑每种情况。每个未考虑的案例都是潜在的错误。

而且你的尝试捕获隐藏了你没有想到的错误。您希望异常冒出，以便您注意到它们并解决根本问题。

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

于 2013-08-02T17:41:14.880 回答
3

在循环中使用 try/catch 很糟糕（30k - 40k 次）？

仅当您预计会有大量异常时。如果不抛出异常，则性能开销很小。

它们仅用于调试吗？

不，但主要用于在运行时查找错误（主要是一个记录异常，以便您可以查看程序崩溃的位置/原因）。您无法预料到所有可能发生的情况，因此拥有一个日志以便在它发生崩溃时进行查阅非常有帮助。

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

以下是非常有问题的：

catch
{
//nothing
}

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

于 2013-08-02T17:42:18.727 回答
2

try-catch从性能的角度来看，当代码在块中运行而不是在块中运行时，性能会受到很小的影响。查看不抛出异常时，try/catch 块是否会损害性能？以获得差异的经验证据。

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

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

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

于 2013-08-02T17:41:33.487 回答