我应该在抛出异常的情况下留下不可达的中断吗？

无论如何抛出一个异常的情况下离开无法到达的break语句是否很愚蠢？在逻辑改变的情况下，我的防守部分想要离开它。我的另一部分不希望其他开发人员在我的代码中看到编译器警告（“检测到无法访问的代码”）。我应该在抛出异常的情况下留下不可达的中断吗？

switch (someInt) 
{ 
    case 1: 
     // Do something 
     break; 
    case 2: 
     // Do something else 
     break; 
    case 3: 
     // Oh, we don't use threes here! 
     throw new Exception("Business rules say don't use 3 anymore"); 
     break; // Unreachable...until the fickle business rules change... 
    default: 
     throw new Exception("Some default exception"); 
     break; // Unreachable...until...well, you get the idea. 
}

怎么办？

UPDATE

我看到一些答复说，在以后的日子取出扔会导致编译器错误。然而，简单地删除（或注释）抛出之后不会中断，会叠加这些情况，这可能是非预期的行为。我并不是说这是一种可能的情况，但是......呃，防御性的编程只关于可能的情况？

来源

2012-03-29 Tim Lehner

'break'不再需要，我将它们删除，因为我将警告作为错误进行构建。 – asawyer 2012-03-29 21:56:30

有趣的问题 - 我最初的反应是包含break语句，但我认为这完全归结于习惯。 – KazR 2012-03-29 21:59:15

编译指示警告禁用，如果你觉得你的担心是有效的，但不想给别人带来不便，但是过分防御可能会迅速混乱你的代码库 – Michael 2012-03-29 22:09:23

我d删除它们。有几个原因：

你并不需要他们的时刻
看到许多警告，总是让我紧张，因为你可能会失去从这个类型的警告传来的噪音真实警告（假设你有警告的错误关闭）。

来源

2012-03-29 21:57:23 gbanfill

你会如何错过“真正的错误？”无论是你的代码不会编译，或者你已经决定警告不是一个“真正的错误”（即你不用“将警告视为错误”标志）。 – Michael 2012-03-29 22:02:47

如果您在上面生成了150条警告，并且您引入了一些会生成有用警告的内容，则很容易错过。 – gbanfill 2012-03-29 22:04:38

我的防御部分想要在逻辑改变的情况下离开它。

确切的逻辑在这里可以改变吗？当引发异常时会发生什么记录非常好。而且我认为你可以合理地确信，以后对C＃的修改不会影响到“迄今为止编写的所有程序都不再有效”的重大改变。

即使没有编译器警告，冗余代码也不是一件好事，除非代码可能在日常维护过程中通过防止错误发挥作用，在这种情况下我们不能合理地说这种可能性存在。

来源

2012-03-29 21:56:36 Jon

我认为他的意思是如果异常被移除，但即使这样也不是问题因为你必须有一个或另一个。 – 2012-03-29 21:57:26

也许我在那里使用了错误的术语，但是不，我并不是说如果C＃规范发生变化，只会变幻无常的业务规则。 – 2012-03-29 22:10:51

在逻辑改变的情况下，我的防守部分想让它留在那里。

那么，如果你删除了throw并忘记添加一个break编译器会让你知道。

我看不出有什么理由让休息时间到来。这是多余的，你只会触发一个警告，所以我会删除它。没有充分的理由让你的逻辑混乱无用的代码。

来源

2012-03-29 21:57:02

简单地删除没有中断的投掷将堆叠案件，这可能是意外的行为。 – 2012-03-29 22:03:27

@TimLehner：这是真的，因为身体是空的。这就是说...如果你把身体留空了，那么我认为你这样做是有原因的。我希望你能相信你的同事知道交换机工作的基本知识。 – 2012-03-29 22:07:32

难道我们都不希望有同样的事情吗？ :) – 2012-03-29 22:08:08

我想删除它。

它摆脱了警告，即使逻辑要改变和被删除的异常，你会收到一个编译器错误说，休息需要添加回来。

来源

2012-03-29 21:57:18 Brandon

不仅仅是一个警告，它会是一个错误。 – 2012-03-29 21:58:07

@EdS，你说的对，我的错。 – Brandon 2012-03-29 21:58:38

其实有一种情况我们都是错的。如果异常被移除并且没有添加任何内容，那么主体将是空的，并且允许在没有警告或错误的情况下通过。 – 2012-03-29 22:08:16

通过忽略一些编译器警告，您正在强化忽略任何编译器警告的不良行为。在我看来，这比在离开break报表时所获得的优势更大。

编辑：我删除了关于编译器迫使你把break语句回如果throw声明是要删除我原来的观点。正如Payo指出的那样，在某些情况下，编译器不会。它只是将案例与下面的案例结合起来。

来源

2012-03-29 21:57:38 FishBasketGordo

如果案例没有其他代码（在评论throw后），编译器不会强制您添加中断。 – payo 2012-03-29 22:26:01

你说得对。在这种情况下，程序员有责任编写好的代码。 – FishBasketGordo 2012-03-30 15:03:31

就我个人而言，我永远不会在生产代码中留下无法访问的代码。测试很好，但不要这样做。

你永远不会这样做吗？

public void MyMethodThatThrows() 
{ 
    throw new Exception(); 
    return; // unneeded 
}

so so keep the break？

来源

2012-03-29 21:58:21

我了解这口井的第一部分，这是一个很好的观点。然而，这个例子有点像稻草人，因为虽然我不会把一个回报放在一个空白内，但我肯定会在一个开关内部留下一些空隙。当然，这个问题是关于休息而不是交换中的回报，因为我是一个退出类型的人。 – 2012-03-30 04:26:22

@TimLehner，哈，好点。我的例子基本上只是夸大了这个问题。 – 2012-03-30 05:22:15

我不会“隐藏”它在switch。我会尽快抛出ArgumentExceptions。这避免了副作用，也更加透明。

有人可能会对它采用someInt虽然是3

例如一些点开关之前添加代码：

public void SomeMethod(int someInt) 
{ 
    if (someInt == 3) 
     throw new ArgumentException("someInt must not be 3", "someInt"); 

    switch (someInt) 
    { 
     // ... 
    } 
}

来源

2012-03-29 21:59:36

极好的点和一个伟大的代码气味。 – 2012-03-30 04:29:42

我希望我的项目源代码是如此冷静和故障少，即我不得不考虑这样的小规模防御性编程:)

我的意思是在软件开发中存在许多缺陷 - COM和Interop，安全/权限和身份验证，证书，......天哪，不能告诉你如何我必须写很多代码来保护自己免于在脚下射击。

只是删除这个休息时间，因为它是多余的，对于知道'案件'应该以break或return结束并且应该对不知道这一点的同伴很明显的同伴来说，这会让人困惑。

来源

2012-03-29 22:51:22

没错，这不是人生中最大的问题。现在，以回报结束的案件绝对有争议...... – 2012-03-30 04:39:55

MSDN C# Reference states：“在每个大小写块之后都需要跳转语句，例如中断，包括最后一个块，无论它是一个case语句还是一个默认语句。”

那么，不是“扔”构成了“跳跃声明”？我认为它确实如此。因此，不需要“休息”，并且“不可达”问题消失。 :)

来源

2013-05-03 21:01:42

该OP承认，“休息”不是必要的，但正在考虑让他们在防守端。考虑如果您决定除了抛出异常之外做其他事情会发生什么。 – jerry 2013-05-03 21:31:14

我应该在抛出异常的情况下留下不可达的中断吗？

回答

相关问题