Java异常处理习语......谁是对的以及如何处理它？

我目前与熟人有技术上的不同点.简而言之,这两种基本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:
    ...
    }
}

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

"这是一个很好的模型.自从我和我的一位朋友在1998年,大约10年前提出它以来,我已经习惯了.再看看你会看到我们对学术论点的妥协做了很多感觉."

对于为什么选择1是要走的路,有没有人有一个可摧毁的论点？

当你有一个switch语句时,你就不那么面向对象了.还有更多的错误机会,忘记" break;"声明,忘记添加一个案例,Exception如果你添加一个新Exception的抛出.

我也发现你的方式更具可读性,这是所有开发人员都会立即理解的标准习惯.

根据我的口味,做熟人方法的锅炉板数量,与实际处理异常无关的代码量是不可接受的.实际程序逻辑周围的样板代码越多,代码读取和维护的难度就越大.使用一种不常见的习语使代码更难理解.

但是,正如我上面所说,交易破坏者是当你修改被调用的方法以便抛出一个额外的时候Exception,你会自动知道你必须修改你的代码,因为它将无法编译.但是,如果您使用熟人的方法并且修改被调用的方法以抛出各种各样的方法AppException,那么您的代码将不会知道这种新变种有什么不同,并且您的代码可能会因为不合适的错误处理段而无声地失败.这假设您实际上记得存入默认值,因此至少它被处理而不是默默地被忽略.

选项2的编码方式,任何意外的异常类型都将被吞噬!(这可以通过在默认情况下重新投掷来修复,但这可能是一个丑陋的事情 - 更好/更有效率而不是首先抓住它)

选项2是手动重新创建最有可能在引擎盖下执行的选项1,即它忽略了语言的首选语法,以便使用最旧的构造,以避免出于维护和可读性的原因.换句话说,选项2是使用比语言结构提供的更粗略的语法重新发明轮子.

显然,两种方式都有效; 选项2仅由选项1支持的更现代的语法废弃