使用默认情况始终是一个好习惯。我什至在打开枚举时使用它。如果枚举有 3 个值，则有 3 个 case 语句，以及一个抛出 AssertionError 的 case 语句。
这很好，因为如果扩展枚举，则可以确保很快检测到与 switch 语句中缺少新值相关的错误。
Using a default case is always a good habit. I even use it when switching on an enum. If the enum has 3 values, I have 3 case statements, and one case statement that throws an AssertionError.
This is good because if the enum is extended, it is ensured that errors related to missing the new values in switch statements will be detected soon.
There is nothing wrong with the default case. In fact, I believe it should almost always be used to throw an error to indicate a faulty value in the switch.
The only thing I can think of that might of lead you professor to make such a statement, is his or her belief that you data should have been validated before reaching a case statement. i.e. If you are programming well, your cases will reflect every contingency.
Well, if that were the case, then we would not need exceptions, period. The whole idea of exceptions is to handle unanticipated conditions. If it was reasonably anticipatable, you would handle it.
So, throw an exceptions in your switch default statements by all means.
As to how they work internally? I am sure there are many possible implementations, but logically, the default case is just the final else clause in a long chain of if..then..if..then..else's.
Yes it's good practice to use the default case, because if at later time you change the condidtions or enumerations you use in your switch-statement, the application does behave "less incorrect" than it would if the new values weren't covered at all. Sorry to say, but IMO your teacher has a bit to catch up with more recent programming methodologies.
Internally it works that way, that the default branch is used in case, the condition does not match any of the other listed conditions.
Other answers mostly state, basically, "when you switch/case on X, and X's type allows X to be 1, 2, 3, etc. (integer), or Red, Blue, Fucsia, etc. (enum), be sure to handle the etc!!". Obvious, isn't it?
On the other hand, when you believe that X, as a variable, because of program flow, will never take on the value "etc"... think otherwise, because it will, eventually. That's the general advice.
Deviating from Java/Pascal to put this in perspective: What if X's type would not allow for "etc"? (say, a "very strict" enum or a range (for integers)). That is, the compiler ensures the possible values are never "etc". And it flags unhandled cases as errors. Would be nice. :-) Functional languages have pattern-matching and algebraic types, which sort of goes this way, but I have no relevant experience there. :(
Back to Java (and similar languages), because you can implement types (classes), you can implement strict checking, e.g. by doing the "case" as a method call taking lambdas/functions/function objects...
发布评论
评论（7）
我认为不使用它是一个坏习惯。
：
这是帕斯卡，只是为了证明你的老师错了
I would consider it a bad habit not to use it.
Edit:
This is Pascal, just to prove your teacher wrong
使用默认情况始终是一个好习惯。我什至在打开枚举时使用它。如果枚举有 3 个值，则有 3 个 case 语句，以及一个抛出 AssertionError 的 case 语句。
这很好，因为如果扩展枚举，则可以确保很快检测到与 switch 语句中缺少新值相关的错误。
Using a default case is always a good habit. I even use it when switching on an enum. If the enum has 3 values, I have 3 case statements, and one case statement that throws an AssertionError.
This is good because if the enum is extended, it is ensured that errors related to missing the new values in switch statements will be detected soon.
默认情况下没有什么问题。事实上，我相信它几乎应该总是用于抛出错误以指示开关中的错误值。
我能想到的唯一可能导致您教授做出这样的声明的事情是，他或她相信您的数据应该在达成案例声明之前得到验证。也就是说，如果你编程得好，你的案例将反映每一种意外情况。
好吧，如果是这样的话，那么我们就不需要例外了。异常的整个想法是处理意外情况。如果这是合理预期的，你就会处理它。
因此，请务必在 switch 默认语句中抛出异常。
至于他们内部是如何运作的？我确信有很多可能的实现，但从逻辑上讲，默认情况只是 if..then..if..then..else 长链中的最后一个 else 子句。
There is nothing wrong with the default case. In fact, I believe it should almost always be used to throw an error to indicate a faulty value in the switch.
The only thing I can think of that might of lead you professor to make such a statement, is his or her belief that you data should have been validated before reaching a case statement. i.e. If you are programming well, your cases will reflect every contingency.
Well, if that were the case, then we would not need exceptions, period. The whole idea of exceptions is to handle unanticipated conditions. If it was reasonably anticipatable, you would handle it.
So, throw an exceptions in your switch default statements by all means.
As to how they work internally? I am sure there are many possible implementations, but logically, the default case is just the final else clause in a long chain of if..then..if..then..else's.
是的，使用默认情况是一个很好的做法，因为如果稍后您更改在 switch 语句中使用的条件或枚举，则应用程序的行为确实比根本没有覆盖新值时“不那么不正确” 。
很遗憾地说，但在我看来，你的老师已经有点赶上最新的编程方法了。
在内部，它的工作方式是，在条件与任何其他列出的条件不匹配的情况下使用默认分支。
Yes it's good practice to use the default case, because if at later time you change the condidtions or enumerations you use in your switch-statement, the application does behave "less incorrect" than it would if the new values weren't covered at all.
Sorry to say, but IMO your teacher has a bit to catch up with more recent programming methodologies.
Internally it works that way, that the default branch is used in case, the condition does not match any of the other listed conditions.
恐怕你的老师错了。设置默认情况是一个很好的做法。
I'm afraid your teacher is wrong. It's a good practice to have a default case.
关于这个问题的另一种看法：
其他答案基本上基本上是这样说的：“当你切换/区分 X 时，X 的类型允许 X 为 1、2、3 等（整数），或红色、蓝色、紫红色等。 （枚举），一定要处理等等！！”。很明显，不是吗？
另一方面，当您相信 X 作为一个变量，由于程序流的原因，永远不会采用值“etc”时……否则，因为它最终会出现。这是一般建议。
从 Java/Pascal 的角度来看：如果 X 的类型不允许允许“etc”怎么办？ （例如，“非常严格”的枚举或范围（对于整数））。也就是说，编译器确保可能的值永远不会是“etc”。它将未处理的情况标记为错误。那就太好了。 :-) 函数式语言具有模式匹配和代数类型，这有点像这样，但我在那里没有相关经验。 :(
回到 Java（和类似的语言），因为您可以实现类型（类），所以您可以实现严格检查，例如通过将“case”作为采用 lambdas/functions/function 的方法调用来执行物体...
Another take on the issue:
Other answers mostly state, basically, "when you switch/case on X, and X's type allows X to be 1, 2, 3, etc. (integer), or Red, Blue, Fucsia, etc. (enum), be sure to handle the etc!!". Obvious, isn't it?
On the other hand, when you believe that X, as a variable, because of program flow, will never take on the value "etc"... think otherwise, because it will, eventually. That's the general advice.
Deviating from Java/Pascal to put this in perspective: What if X's type would not allow for "etc"? (say, a "very strict" enum or a range (for integers)). That is, the compiler ensures the possible values are never "etc". And it flags unhandled cases as errors. Would be nice. :-) Functional languages have pattern-matching and algebraic types, which sort of goes this way, but I have no relevant experience there. :(
Back to Java (and similar languages), because you can implement types (classes), you can implement strict checking, e.g. by doing the "case" as a method call taking lambdas/functions/function objects...
这确实取决于。如果没有默认值，则不需要它。
It really depends. If there's no default, you do not need to have it.