Answers:
这是一个有用的示例。
public Collection<LogItems> GetAllLogItems(Level level) {
Collection<LogItems> result = new Collection<LogItems>();
switch (level) {
// Note: fall through here is INTENTIONAL
case All:
case Info:
result.Add(GetItemsForLevel(Info));
case Warning:
result.Add(GetItemsForLevel(Warning));
case Error:
result.Add(GetItemsForLevel(Error));
case Critical:
result.Add(GetItemsForLevel(Critical));
case None:
}
return result;
}
我认为这种事情（其中一种情况包括另一种情况）非常少见，这就是为什么一些较新的语言要么不允许失败，要么需要特殊语法的原因。
// INTENTIONAL FALL THROUGH HERE注释。
GetItemsForLevel(Info)调用调用GetItemsForLevel(Warning)等等来编写此代码很容易。
当某些功能必须应用多个值时，我会使用它们。例如，假设您有一个对象，其对象名为operationCode。如果代码等于1、2、3或4，则要启动OperationX（）。如果是5或6，则要startOperationY（），要7，则要startOperationZ（）。当您可以使用穿透功能时，为什么要有7个完整的功能案例和中断案例？
我认为这在某些情况下是完全有效的，尤其是避免使用100条if-else语句时。=）
switch与多个case绑定到同一代码的。这与失败（fall-through）不同，后者case由于在break两者之间缺少a ，因此继续执行到下一个。
掉线的情况很好。我经常发现在很多地方都使用了枚举，并且当您不需要区分某些情况时，使用穿透逻辑会更容易。
例如（请注意解释性注释）：
public boolean isAvailable(Server server, HealthStatus health) {
switch(health) {
// Equivalent positive cases
case HEALTHY:
case UNDER_LOAD:
return true;
// Equivalent negative cases
case FAULT_REPORTED:
case UNKNOWN:
case CANNOT_COMMUNICATE:
return false;
// Unknown enumeration!
default:
LOG.warn("Unknown enumeration " + health);
return false;
}
}
我发现这种用法完全可以接受。
case X: case Y: doSomething()和之间有很大的区别case X: doSomething(); case Y: doAnotherThing()。在第一个中，意图是很明确的，而在第二个中，失败可能是有意的，也可能不是有意的。以我的经验，第一个示例从不会在编译器/代码分析器中触发任何警告，而第二个示例会触发。就个人而言，我仅将第二个示例称为“失败”-但是不确定“官方”定义。
这是一个失败的快速（公认的不完整（no年没有特殊处理））示例，它使我的生活更简单：
function get_julian_day (date) {
int utc_date = date.getUTCDate();
int utc_month = date.getUTCMonth();
int julian_day = 0;
switch (utc_month) {
case 11: julian_day += 30;
case 10: julian_day += 31;
case 9: julian_day += 30;
case 8: julian_day += 31;
case 7: julian_day += 31;
case 6: julian_day += 30;
case 5: julian_day += 31;
case 4: julian_day += 30;
case 3: julian_day += 31;
case 2: julian_day += 28;
case 1: julian_day += 31;
default: break;
}
return julian_day + utc_date;
}