Question

下面的代码是不好的做法？

 try //Try Overall Operation
      {
           try //Try section 1 of operation
               {

               }
           catch(exception ex)
               {
                    //handle exception code
                    //throw the exception
       }
 catch (exception ex)
      {
          // send soap exception back to SOAP client.
      }

我从程序审查的角度来看，其他开发人员看到直接嵌套的2次尝试可能会想知道为什么，但它是完全禁忌，还是现在被接受的练习？

谢谢大家，我同意你们关于重构的一切，为子功能创建一个单独的方法，这个方法变得非常长。对于那些选择了这个的人，我印象非常深刻......

Answer 1

没有。我认为这根本不是坏事。

如果你在第一个嵌套的尝试中做了一些事情，你可以捕获并正确处理，这非常好，特别是如果你在两个处理程序中“捕获”不同类型的异常。

但是，我会说这是可能重构的好机会，并将嵌套部分拆分为单独的方法。通常，当我看到这个时，它表明该方法应该分成更小的方法。但是，情况并非总是如此。

Answer 2

在我看来，它不一定是。有时您希望第一次尝试中的某些代码执行，即使第二次尝试中的代码失败也是如此。

也可以补充一点，其他人对他们所说的也是正确的。我只是说它不一定总是坏。在一个不要求性能的程序中，你可以随心所欲地做到这一点。

Answer 3

这取决于您的计划需要做什么。通常最好将try/catch包裹在尽可能小的工作范围内，并尽可能缩小您的异常处理范围，以避免意外行为，副作用或错误。很多时候这意味着有一系列try/catch块，这很好。

Answer 4

我认为这取决于你如何处理内部异常。你的内部捕获需要做一些完全不同于外部捕获范围的东西，这可能是非常符合逻辑的。您要避免的一件事是将内部异常隐藏为外部异常的原因。换句话说，我强烈推荐

try
{ 
     // Do something 
     try
     {
         // Do something
     }
     catch(MyException e)
     {
         // handle
         throw; // <--- This is important, it rethrows the same exception while maintaining the stack trace.  This is *different* from "throw e"
     }
}
catch(AnotherException e)
{
    // handle 
}

Answer 5

只要逻辑保证，这不是一种不好的做法。

例如，如果最外层try用于捕获SQL异常，而最内层try用于IO异常，则执行此操作可能是合理的。

但是，请注意避免使用涵盖大量代码行的catch-all try子句。那些不是好习惯。

Answer 6

不，这不一定是不好的形式。

就像大多数这些类型的问题一样（例如是goto evil？，是（（;）邪恶？）这些东西都有它们的位置，如果需要它们就可以使用。

Answer 7

如果有一个例外，你可以在第一个试块中处理并仍然继续成功，我认为它没有任何问题。如果它只是做某事并重新抛出，只需为你要查找的特定类型的异常添加另一个catch块并在那里处理它。

Answer 8

这并不可怕，但是看看你是否可以通过在必要时处理Exception类型来解决这个问题：

try
{

} 
catch (SqlException ex )
{
// Catches specific exception
}
catch ( Exception ex )
{
// Catch-all
}

每当你做一次尝试捕捉时，你就会创建另一个语句线程来阻碍可读性。 E.g：

try
{
   try
   {
   }
   catch ( Exception ex )
   {
   }
}
catch ( Exception ex )
{
}

在C＃中嵌套2个try catch语句是不好的做法吗？

8 个答案: