Java异常处理习语...谁说的对，怎么处理？

Question

我目前和一个熟人有技术上的分歧。简而言之，这就是 Java 异常处理的这两种基本风格之间的区别:

选项 1(我的):

try {
...
} catch (OneKindOfException) {
...
} catch (AnotherKind) {
...
} catch (AThirdKind) {
...
}

选项 2(他的):

try {
...
} catch (AppException e) {
    switch(e.getCode()) {
    case Constants.ONE_KIND:
    ...
    break;
    case Constants.ANOTHER_KIND:
    ...
    break;
    case Constants.A_THIRD_KIND:
    ...
    break;
    default:
    ...
    }
}

他的论点——在我使用大量关于用户输入验证、异常处理、断言和契约等的链接来支持我的观点之后——归结为:

“这是一个很好的模型。自从我和我的一个 friend 在 1998 年提出它以来，我就一直在使用它，差不多 10 年前。再看一眼，你会发现我们对学术论点所做的妥协很有道理。”

对于为什么选项 1 是要走的路，有没有人有充分的论据？

Answer 1

当你有一个 switch 语句时，你就不那么面向对象了。出错的机会也比较多，忘记一个“break;”语句，如果你添加一个新的Exception，忘记为一个Exception添加一个case > 被抛出。

我还发现您的做法更具可读性，而且这是所有开发人员都会立即理解的标准习惯用法。

以我的口味，做你熟人的方法的样板数量，与实际处理异常无关的代码数量，是 Not Acceptable 。实际程序逻辑周围的样板代码越多，代码就越难阅读和维护。使用不常见的习语会使代码更难理解。

但是，正如我上面所说，破坏交易的是，当您修改被调用的方法以使其抛出额外的 Exception 时，您会自动知道您必须修改代码，因为它会失败编译。但是，如果您使用熟人的方法并修改被调用的方法以抛出新种类的 AppException，您的代码将不知道这个新种类有什么不同，并且您的代码可能会默默地失败下一个不适当的错误处理腿。这是假设您确实记得输入默认值，所以至少它已被处理并且没有被默默地忽略。