做个接口用来记录error message，继承接口，创建个ActionMessages的适配器，service层只传递那个接口，隔离struts。

这种做法跟我们的一样，日本人的办法。跟他们说不好，又不肯改

Services 只抛出异常
Actions 负责扑捉异常
这样可以吧？

没错，
定义自己的应用异常，
异常里面可以自定义错误编号，错误信息等错误信息，actions可以统一处理。

对于简单应用，就在服务层抛出的地方定义错误编码，然后再action中捕获。
我一般都是
throws new ServeciException("error.username.isexist",e);
当然，每个层最好还是定义个异常类。

在我刚完成的一个项目里面是这样实现的，业务逻辑端抛出异常，利用struts对exception，在配置文件中配置好exception和他是怎么处理的，比如写ID，错误信息，forward到那个叶面等等。但是这样做有不好的地方就是业务逻辑抛出的异常很难得到更加详细的信息。只能是很简单的一个exception。不知道其他人是怎么做的。

5楼说的对，我认为最好的办法就是每层定义一个异常类

在每层定义不同的exception（继承java.lang.Exception）是异常处理应该遵循的，如文件操作异常，定义一个FileException，如果数据库操作异常，定义DBException，等等。层层捕获，层层抛出，在web.xml中定义各个exception的显示页面，如果不希望每个exception都定义，那就定义一个java.lang.Exception的显示页面就ok了，是繁是简，自己都是可以控制的

看来大部分人认为应该是在服务端定义好相应的Exception，然后在表现曾更具得到的Exception来进行相应的处理。但是这种Exception最好是RuntimeException或者说是UncheckedException，就是不是必须显示处理的。因为表现曾上不一定识别Exception的能力。例如如果服务端要暴露成Webservice，这是就不适合用CheckedException。

个人认为service层应该将一些business exception作为checked exception, 抛出到 controller层, 这样做的好处是:

1.这样和error code 的形式想比会使这种business exception显示的表示, 会有type check之类的益处, 同时异常的名字会很清晰的表明它的业务意义.
2.会强迫controller层对这个异常进行处理(或者继续向上抛)

尽管有这些益处,但缺点也有:
1.有时会造成business exception过多的情况, 业务方法的throws 语句会很长,使得业务方法看起来很Ugly.
2.因为是checked exception,一旦service 层的业务方法增加一个异常,将使得controller受到影响, 这种影响会从service层向外传播.

针对缺点 1, 应该谨慎设计一些业务方法, 如果发现抛出的business exceptin过长, 问问自己是不是这个方法承担的责任太多, 或者一些business exception可以合并为一个有意义的异常.
针对缺点 2, 没有办法,这是checked exception的特点, 任何事物都是两面性.

一般的business exception都会在controller层try/catch，返回相应的信息到客户端, 目的是告诉客户问题出在哪里，让他们恢复.所以我们可以认为这些异常是可恢复的异常,这是business exception作为checked exception的一个理由.