在一个只抛出异常的情况下,将无法达到的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.
}
怎么办?
更新
我看到一些回复说在以后删除抛出会导致编译器错误。但是,简单地删除(或评论)抛出后不会中断它会堆叠案例,这可能是非预期的行为。我并不是说这可能是一种情况,但是......好吧,是否只是针对可能出现的情况进行防御性编程?
答案 0 :(得分:7)
我删除它们。有几个原因:
答案 1 :(得分:7)
我不会"隐藏"它在switch
。我会尽快抛出ArgumentExceptions
。这避免了副作用,也更加透明。
有些人可能会在切换之前在使用someInt
的某个点添加代码,尽管它是3。
例如:
public void SomeMethod(int someInt)
{
if (someInt == 3)
throw new ArgumentException("someInt must not be 3", "someInt");
switch (someInt)
{
// ...
}
}
答案 2 :(得分:2)
通过忽略某些编译器警告,您正在强化忽略任何编译器警告的不良行为。在我看来,这比从break
语句中获得的任何优势都要大。
编辑:我删除了关于编译器的原始观点,如果要移除break
语句,则强制您重新插入throw
语句。正如payo指出的那样,在某些情况下,编译器不会。它只会将案例与下面的案例结合起来。
答案 3 :(得分:2)
就个人而言,我永远不会在生产代码中留下无法访问的代码。这对测试很好,但不要这样做。
你永远不会这样做吗?
public void MyMethodThatThrows()
{
throw new Exception();
return; // unneeded
}
为什么要保留break
?
答案 4 :(得分:1)
我会删除它。
它消除了警告,即使逻辑要更改并且要删除Exception,您也会收到编译器错误,说明需要重新添加一个中断。
答案 5 :(得分:0)
我的防守部分想要将它留在那里 逻辑变化。
这里有什么逻辑可以改变?抛出异常时会发生什么很好。而且我认为你可以合理地确定C#的后期修订不会影响到“迄今为止编写的所有程序都不再有效”的重大变化。
即使没有编译器警告,冗余代码也不是一件好事,除非代码可能通过防止日常维护中的错误发挥作用,在这种情况下我们无法合理地说这种可能性存在
答案 6 :(得分:0)
如果逻辑发生变化,我的防守部分希望将其留在那里。
好吧,如果您删除throw
并忘记添加break
,编译器会通知您。
我认为没有理由在那里休息。它是多余的,你只会触发警告,所以我会删除它。没有充分的理由留下无用的代码来破坏你的逻辑。
答案 7 :(得分:0)
我希望我的项目资源非常酷且无故障,我不得不考虑这些防御性编程的小案例:)
我的意思是在软件开发中存在许多陷阱 - COM和Interop,安全/权限和身份验证,证书,......天哪,不能告诉你我需要写多少代码保护自己不要在脚下射击。
只是删除这个中断,因为它是多余的,对于那些知道“案例”应该以{{1}}或break
结尾并且应该对那些不知道这一点的人来说显而易见的人来说,这是令人困惑的。
答案 8 :(得分:0)
MSDN C# Reference表示:“每个案例块后都需要一个诸如中断之类的跳转语句,包括最后一个块,无论是case语句还是默认语句。”
那么,“扔”不构成“跳跃声明”吗?我认为确实如此。因此,不需要“休息”,并且“无法到达”的问题消失了。 :)