现在的异常体系设计是：系统内部所有异常继承同一个基类BaseException，BaseException又继承RuntimeException。在一个层次（例如DAO层或者Business Service层）中有一个异常基类，对于每种具体的出错情形再派生一个新的异常类，例如UserCannotFound、HaveNoPermission等等。

这样做的好处是避免了在接口上出现异常签名，因为“抛出哪种异常”是方法的私事。如果接口签名上指明详细的异常信息，又采用Checked Exception，当方法内部实现改变时，接口就会受到影响；如果接口签名上只泛泛地标注一个高层次异常（例如Exception甚至Throwable），又起不到任何提示的效果。

但是接口上不留异常签名又带来另一个问题：client程序员要到运行时（甚至可能要过相当长的时间）才知道这个方法可能抛出哪些异常，给编写代码造成相当大的麻烦。我想的折中办法是：（1）方法稳定之后，在接口上标注异常签名，由于全部异常继承RuntimeException，即使接口异常签名改变也不会破坏client；（2）用一个拦截器把所有异常log到统一的地方，并提供足够的信息，方便调试。

ExceptionHandler 异常处理 来自 冰云@Blogging

我现在的异常处理和你做的差不多。每一层都有BaseUnckeckedException，但有时候也用CheckedException。以前在onjava看到过一篇讨论受它影响比较深。对于无法处理的异常，就用UnChecked，例如SQL错误，产生于DAL，对于系统的来说是致命的。交给BusinessLayer毫无用处，因此抛出DaException。如果是有用的可处理的例如处理用户登录的时候，UserNotExistException或PasswordNotVerfiedException就用CheckedException，交给Client去处理，显示不同的信息。 另外，在处理异常方面，我现在采用的是Struts1.1的ExceptionHandler机制。在ExceptionHandler捕获所有的Throwable，然后交给一个统一的或者按照module区分的Error.Jsp页面来显示。 另外有一个问题就是i18n在异常中如何处理。抛出的异常最终会显示到界面上。如果不做任何i18n处理恐怕不够友好。因此我让所有的自定义Exception实现一个ErrorKeyable接口。包含的Error就是i18n的key。如果我在ExceptionHandler中得到的Exception是ErrorKeyable的实例，那么就显示定制的错误信息。如果不是，就显示Unkown Error，呵呵。然后做个按钮在错误页让用户提交给admin。

早就想写一篇异常处理的文章。今天看到gigix写了一篇《The Dilemma of Exception》
基于他的观点，我也写了一点东西。基本上，思路是一致的。

trackback不能用真是郁闷。

我现在的异常处理和gigix做的差不多。每一层都有BaseUnckeckedException，但有时候也用到CheckedException。以前在onjava看到过一篇讨论受它影响比较深。对于无法处理的异常，就用UnChecked。例如SQL错误，产生于DAL，对于系统的来说是致命的。交给BusinessLayer毫无用处，因此抛出DaException。如果是有用的可处理异常就应该处理。例如用户登录的时候会产生UserNotExistException或PasswordNotVerfiedException，就用CheckedException，交给Client去处理，以显示不同的信息。 Gigix的异常签名方法看起来很好。下次可以试试看。将Exception标记在javadoc中也是应该考虑的事情。在处理异常方面，我现在采用的是Struts1.1的ExceptionHandler机制。用ExceptionHandler捕获所有的Throwable，交给一个统一的或者按照module区分的Error.Jsp页面来显示。 有一个问题就是在异常中如何处理i18n。抛出的异常最终会显示到界面上。如果不做任何i18n处理恐怕不够友好。因此我让所有的自定义Exception实现一个ErrorKeyable接口。包含的ErrorKey就是i18n的key。如果我在ExceptionHandler中得到的Exception是ErrorKeyable的实例，那么就显示定制的错误信息。如果不是，就显示Unkown Error，呵呵。当然，对于后台产生的错误以及Exception的Message，服务器的locale基本不变，并且log只有开发人员或网管才看。因此i18n毫无用处，所以内部的ExceptionMessage采用中文或者英文均可。我是采用英文，因为中的的话，不同的编译环境还可能导致乱麻。还不如英文呢简单。最后做个按钮在错误页上，一旦产生错误，就让用户按按钮将错误信息提交给admin以便记录。 后台已经有了log为什么还要这样做哪？以上的部分已经在项目中实施，基本上比较方便。不用看到Tomcat中蓝色Stupid错误提示。