【事情起因】 最近在看《Java编程思想》第4版，昨天看到异常处理那章时，就想到了J2EE项目中异常的处理，J2EE的项目光在后台打印出异常还是不够的，需要以一种友好的方式提示给用户。
【事情经过】 于是我就看了之前在公司做的项目，这才发现，在struts里，我们都是
try{
xxxxxxxxxx
}catch(BunisessException e){
throw new BunisessException("xxXXXXX，请确认后重试");
}
就是自己将我们自定义的异常抛出去，却重来没有管他如何在页面上展示。我运行起项目，当故意进行错误操 作时，后台我throw Exception的信息，总能以很友好的对话框显示出来。仔细查看没个页面，却没有任何的异 常的提示信息。
【思考】那么异常信息时如何弹出来的？
我直觉告诉我，肯定有一个公共的页面用来进行错误提示。带着这个问题，我看了项目中所有的公共页面的代码。
直到发现一个ErrorAler.jsp的页面。这个页面比较简单，在页面上写了一段JAVA代码，调用了后的一个类的静态
方法，我跟踪进去，查看该类，发现他继承了一个来自acegi的类，并实现了一个借口springFramework.security
的一个借口。
处理代码很短，但是涉及到其他几个类，大致的意思是:获取到异常堆栈，最后抛出的那个异常，然后getMessage()
然后放置到session中。
这个页面最后会以window.open()的方式打开，看起来就会像一个alert框。
他的实现原理和机制，我还是没懂。由于我家没网，所以不能把代码发上来供大家一起研究。高手能不能大致讲讲这种处理机制？
我所知道的异常处理好像主要有以下几种办法：
1.web.xml里面有个error-page
2.用struts 有个 globel-exception
3.在后台catch 语句块 用request派发到页面，在页面上show
【写在后面】 我会继续去研究，等研究透了，会和大家一起分享的！
------解决方案--------------------
以IBM为例，异常哪些要抛，哪些不抛，哪些要写到日志里面都有比较明确的规定的。按照规定走。把异常当做一种逻辑的一部分看待。
------解决方案--------------------
我所知道的异常处理好像主要有以下几种办法：
1.web.xml里面有个error-page
2.用struts 有个 globel-exception
3.在后台catch 语句块 用request派发到页面，在页面上show
楼主想的不错， 这就是一个大体的流程。 也就是说， 我们把本来在控制台打印的异常信息在页面上也打印了。这对于给懂技术的人来看是由意义的， 但是对于那些单纯面向客户的程序来说， 就没有必要再页面上来显示异常了。
------解决方案--------------------
需要顶层封装一下 配置全局异常弹出页面就好啊
------解决方案--------------------
稍微成熟点的项目组，应该都有自己的异常处理规范或者小框架吧。。。。
------解决方案--------------------
对于楼主所说的用户操作异常这类的，我的做法是将错误信息放到struts的ActionError中，然后在视图层处理：
1，新建一个页面，显示“尊敬的用户您好，您的操作出现了以下错误：”，然后列出ActionError里面的错误内容。
2,在原页面直接显示错误信息。
3，用Javascript控制弹出错误信息提示框。
对于那些非用户操作的异常，比较简单的错误就是跳到一个error.jsp,网站类型的就告知"对不起，系统正在维护！"，非网站的企业级管理系统就告知“系统运行错误，已记录错误日志，请联系维护人员！”。然后记录错误信息日志。
这符合大多数程序员的懒汉思想，包括我，不是不想研究更完善、通用、简易、准确的异常处理方式，觉得够用了就不研究了，经楼主这么一提醒越发觉得我们可耻了，期待有高手整理。。。。
------解决方案--------------------
ER。。。。。。。其实换个思维去想该不该显示
后台出错（就是有异常），当然你就这么个抛了出去，可要想好，哪些异常是属于用户的操作问题，哪些是后台问题，当然后台问题的代码自动处理，大不了就告诉用户服务器出问题，不能访问这样，至于用户操作的，就都不一定都要给用户一个界面说什么什么，有时候后台也可以处理，至于到了非要返回一个信息给用户的，也不用弹出一个窗口，起码我是及其讨厌，可以直接返回本来的页面，然后在个醒目的位置写句话
------解决方案--------------------
之前对于异常处理，百分之八九十都是直接给吞了。说到这个吞字，大家可能不太明白我的意思。但是e.printStackTrace();这条语句如果你在自己的程序中用的比较多的话，那就说明你也是吞异常的高手。然而很遗憾，成为了吞异常的高手，就一定是一个处理异常的低手(这个词太别扭了，改用'菜鸟'吧)！如果把不该吞的异常也给吞了，那就降低了程序和用户(包括二次开发人员、测试人员以及普通用户)之间的交互性。程序如果在出错的时候总是保持沉默，那用户不爽的次数到达一定数量后，最终将极有可能把我们所谓的作品给抛弃。异常处理的重要性已经体现出来了，要不然SUN公司也不会专门搞个异常处理机制了。说到这里，真正需要思考的问题才刚刚开始，如何才能更好地或者说更为合理地进行异常的处理呢？要想成为异常处理的高手，首先肯定得了解产生异常的原因，然后根据原因进行相应处理。究竟是抛，还是不抛(或者说'吞')，这是一个问题；究竟是使用默认异常还是自定义异常，这同样也是一个问题。如果异常是系统内部引起并且是我们能够确定的，比如说一个字符串s在使用getBytes("UTF-8")时出现UnsupportedEncodingException异常，那么就可以把它吞了(或者抛出一个Error)，因为UTF-8是系统支持的基本编码集之一；如果异常是我们无法确定的，那此时就应该向上抛出，比如我们在写一个底层函数，需要进行文件的读写操作，那么很显然会有一个FileNotFoundException异常，这时就应该抛出去；但是如果我们站在更上一层，能够直接面向用户了，这时就得进行异常处理，比如来个信息提示说相应的文件没找到。接着说说自定义异常给我们带来的好处。自定义异常的好处个人认为主要有两点：一是能够更好的进行异常定位；二是能够将同种性质或是类似性质的异常进行归类，向上抛出后方便别人处理。比如给别人提供了一个二次开发函数，作用是读取一个Xml格式的文件，并且通过一系列解密操作，得到原始信息，然后通过这些信息进行相关类的构造。既然是读取文件，那么必然会有一个FileNotFoundException异常，又由于是一个经过加密的xml文件，那么在读取操作时也很有可能会产生诸如xml文件格式不正确、xml节点错误、xml节点内容错误等各种异常情况。对于二次开发人员来说FileNotFoundException异常很方便处理，但后面的几种异常可能会使他产生厌烦。此时，我们就应该使用自定义异常将xml文件格式不正确、xml节点错误、xml节点内容错误等各种异常归并起来，然后向上抛出。于是对于二次开发人员来说，他只需要处理两个异常，一个是FileNotFoundException，另一个则是我们自定义的异常，比如FileContentInvalidException(文件内容无效)异常。因为产生文件内容无效的原因，多半是由于正确产生出的xml文件被非法修改过所造成的。当然了，自定义异常的名称最好也能够见名知意！