Java 接口的异常设计疑惑

是啊，楼上，声明成通用的，其实也是需要调用者参考文档来处理的。不然他捕获了异常也没啥用。

因为异常处理的开销比较大??
这个怎么理解？好像虚拟机处理的时候都差不多的吧，遇到一个异常就停止执行，返回处理。。。

还是听听大虾们怎么理解...

异常的定义，我觉不能离开系统的业务范畴。接中的作用就是定义一个业务功能的入口，下面有可能接用好几个方法来完成这个业务功能。可能根据具体业务实际情况来定义可能出现的一些不符合业务规则的异常。对于一个其它的异常如：集合为空，除非和业务规则有关系，要提示错误信息给用户看要抛出异常外其它的个人感觉直接抛出一个Exception来就行。

如果是业务性的接口，那么接口的异常就表示了业务的异常流；如果是通用的接口（比如框架中的接口），这样的接口我觉得它的业务性就比较不明确了，随着你的不同运用它有不同的业务性，它过多是作为一种机制来使用的，这样接口的定义异常就如我上面的说的那样就仁者见仁了。

这个问题就好比吃饭是用叉子和筷子哪个好?见仁见智,接口作为一种规范,它所定义的范畴是要大于和等于业务范畴的,在接口中显式的抛出具体的异常是不太合适的,但划分的粒度过大又导致业务异常的分类复杂,所以尽量采取倒三角型的输出模式,由上层调用者来细分异常,所以无论是两层、三层或四层结构,其对异常的声明都是不尽相同的,越到底层,接口的声明尽量宽泛,由于运行时异常无须显式的捕获和抛出,所以推荐将底层的异常封装成相应的系统异常抛出,同时对业务层的各种业务异常和其他异常分类捕获,这样不仅代码中减少try..catch块,而且在各层的接口声明上更加松耦合,层与层之间的层次更加宽松,不会在重构时受层层之间的约束,具体问题具体分析,最终还得由决策者来判断

如果业务方法只可能抛出某个特定的异常那就声明为抛出那个具体异常咯。

如果是专业接口 , 设计上有抛出异常比较好 , 但通用接口就最好不要了 ~
比方执行SQL的接口 , 抛出 SQLException , 但作为通用接口就没什么必要了 , 因为可能涉及到其他东西 .
好比 , 通用的电源插座 , 不会在每个插座都标记上会漏电 , 小心防火之类的 .
但专用燃气热水器接口会提示 , 只能应用于天然气 .
这些列举都是最简单的面向对象 .