6

try-catch如下编码一个块是一个好的设计实践吗？即throw在 try 块中使用 a ，然后在 catch 块中捕获它。

try
{
  if (someCondition){

      throw new Exception("Go the the associated catch block!");

     }
}

catch(Exception ex)
{
      logError("I was thrown in the try block above");
}
4

6 回答 6

3

有时您可能想要 - 例如，如果您使用 ado.net，它习惯于将所有东西都扔掉SqlException- 您可能想要捕获其中的一些并处理它们，同时让其他的处理到另一个层次。在这种情况下，您必须捕获 SqlException，看看您是否可以处理它，如果不能处理，则重新抛出它。

于 2012-05-14T18:44:21.023 回答
3

例外情况适用于例外情况。它不应该用作流逻辑的控制，但是如果确实出现了需要处理的边缘情况，那么这样做并没有错。

如果我正在读取的数据不是我所期望的，我自己会在我的代码中抛出一个InvalidDataException 。

于 2012-05-14T18:44:23.997 回答
2

一般来说，如果它是最短的可写方法，它是不错的设计。但请注意，抛出一个 excaption 通常需要大约 1 ms 才能捕获。在这方面，这是一个性能问题。

于 2012-05-14T18:43:54.340 回答
1

这取决于，您应该在通常情况下抛出异常，并且最好是您自己的异常而不是一般异常。

于 2012-05-14T18:44:22.790 回答
1

这完全取决于您要达到的目标。总的来说，最好避免过度使用 try-catch 块，尤其是因为它们很慢。大量的 try-catch 块会让你的代码看起来凌乱且难以理解。

您需要考虑为什么会抛出异常，是意外错误、错误还是预期错误？如果它是预期的错误，那么您应该尝试围绕它编写代码，而不使用 try-catch。

于 2012-05-14T18:46:48.097 回答
1

如果 someCondition 表示真正的错误状态，那么是的。没有问题。但是，请不要用它来控制程序流程。没有什么比看到一个可以退出范围时抛出的异常更让我发疯的了。它也有可能危及对代码中真实异常的正确处理。

于 2012-05-14T19:43:21.767 回答