没有异常处理机制的系统

      先描述一下印象中的公司

      在专业领域内的名头在国内还算挺响的，顶着“国内第一个拥有自主知识产权的.....”、“国家XX计划重点企业”、“某某研发项目国家级、省级领导高度重视”的光环。但对行业了解的人都知道，这仅仅是国内的名头罢了，但即便如此，还是很值得让人尊敬的。公司偏重于C Sharp，做Java的开发人员很少，传言基本上是做完项目就走人了。IT行业，在一个公司呆多长时间算老员工？反正来这个公司后，我第一次接触了好几个年轻的但都已经呆了5年以上的同事。面对许多小企业选美似地的换人周期，这点我感觉公司确实是有着一些优点，能留住一些人的。

       再说说我的简要情况：我08年毕业，无厘头的、阴差阳错、无心插柳却开了花的去了一家软件企业（当时因为无聊+寂寞，于是跟朋友玩去的宣讲会，结果笔试+面试后，一起去的一批就要了我），年轻人浮躁，干了半年沉不住气回家自考去了，结果惨败，从中深刻的认识到了自我很陌生、很人性的的一面。失败后自感无脸面对江东，故而四处奔波逃避，时间一刷的就来到了10年年底，而此时亦感到自己不再那么年轻，时间的流淌让我感觉像是在做最后的挣扎。我急切的想要安定，想要稳定下来。于是在经过了一次面试失败后，我来到了这个公司，面试我的技术人员估计连Struts都没用过，而我也就可怜的半年经验，而且那半年做的所谓开发工作基本上就是copy and modify。对于框架还是云里雾里，甚至都没达到雾里看花，也许九霄云外形容比较好一些。

       刚才说了公司做java开发的人很少，而我似乎可能会重蹈先辈们的覆辙，被公司紧急招来开发一个java项目，据我所知，这是公司当前唯一在开发状态中的java项目，而开发人员，仅我一人。但我想我会坚持下来的，因为我渴望安定下来。下面来描述一下该项目：

       在签该项目（设代号是JCXX项目）之前的08年，公司已经为客户企业开发了一个SRM系统，而JXXX项目正是基于前一SRM系统进行二次开发，扩展一些功能。当我接到项目任命书的那天，项目经理给了我08年开发的那套系统的源代码以及数据库文件，文档有一个项目设计方案，数据模型给了一个数据库表结构查看器（是一个天才的同事开发的），还有就是JXXX项目的项目经理也是08年那个系统开发时的项目经理（他对JXXX业务捻熟，但没用过java及各种类的框架）。可怜的是项目经理在我们还是云里雾里的时候就撂下了挑子结婚去了，而且后面还有其他项目等着他。于是公司派了另一个项目经理级别的人来交接他的工作。这下，我们三（还有一个PB程序员做仓储）都是云里雾里了。。。于是我们艰难的开始了拨开云天见红日的旅程，不幸的是，做PB的同事才刚接触云端便撒手离我们而去—辞职了。诶，做项目就是纠结！

       说了这么多废话，下面进入主题——系统的异常处理

       源码+数据库文件，我想这就足够让我搞定以前的系统了，但是很偶然一次，客户企业使用系统2年后发现某个地方有些问题，项目经理让我在源码里查查，结果是，他给我的源码里根本没有那部分功能（我笑），项目经理让我问另一老一辈同事，他让我从客户企业的服务器上将系统考下来，然后反编译，找出版本之间的差异，凑合着改（我傻了，无语了！）。后来我仗着自己是新人不懂，乱冲乱撞逮着了配置管理员，结果还真幸运，配置库里有更新的版本（我得意的、庆幸的笑了）。当我翻开第一个Action时，我又傻了一瞬间，我暗幸自己毕业后进的第一家软件公司写代码还算规范，没把我往歪路上带；同时我也怀疑自己此刻是不是真实的存在着，我惊叹于他们写代码的天马行空——数据模型、业务逻辑、持久化 统统的在Action里面扎堆，一运行，控制台不时的跳出几行“null、null” 或者“here 到这里了”，我真的很惊喜，因为不至于太寂寞，偶尔还有些字符串朋友们能跳出来跟我打个招呼。但是接下来“忧愁”就伴我一路同行了。系统对异常的处理仅限于printStackTrace()，于是乎我就想，他们在开发的时候是不是跟Exception有仇，这么疯狂的拼了命的要压制它们，甚至都不问他们的出身？！还好，他们在web.xml里面将未捕获的异常都跳转到了一个错误提示页面，于是一个仅仅贴上了"error"招牌的HTML页面常常在我眼前晃悠，我知道，它想招我发狂！但我正想练习我的心态，镇静就好。

       你能想象一下一个只记录了NullPointerException异常的日志文件能对你分析问题有什么帮助吗？很不幸，这个问题就是我需要思考的之一。如果你不需要考虑这类问题，那就当小小见一下世面吧，看我给你小小描述一下：

       某天我进入客户企业的服务器远程桌面，深入项目部署的目录，看到logs文件夹中一列老长的日志文件（文件名还是带日期的）后，我暗笑，原来他们还算有点品位。但有句老话说得好：“油漆的马桶，外头光！”，我打开某个日志文件一看，一段一段的异常信息的带头大哥全是NullPointerException，到这，我知道夸他们有点品位那是夸早了，这不，NullPointerException还是服务器给记下的。谁能告诉我这日志文件除了占地盘外，还能有什么用？这就是霸着茅坑不拉屎的一类！不过我还是有些庆幸自己能有如此难得的际遇，起码以后在写代码的过程中，对那些可能为null的对象的方法或属性的访问会更谨慎一些！还有，我对系统的异常机制也有了自己更深入的思考。下面我想写出来与大家分享一下（如有雷同，只能说明老兄你比我先行了一步，小弟愚钝，是只笨鸟；如果有什么不妥的，还望不吝指点，讨论、学习、进步其乐无穷。套句俗话：“我吃的饭还不如老兄吃的盐多”所以不要见笑了。

       应用系统异常处理的思路：

      1) 将存在的异常分为两类，第一类为诊断系统故障根源的异常，该类异常面向的受众为开发人员，大多都是由被调用的其他模块的接口（如访问数据库的JDBC）抛出的；第二类为提示性异常，该类异常面向的受众为系统的使用者，主要作用是传送异常的文字描述信息，当然，要用客户化的语言来描述。这类异常类由系统框架自行定义，设为 calss ExpFoundException {}。

      2) 对于第一类异常，基本上都是经检查的异常，所以都可以捕获到，对于被捕获之后的处理，第一步：先做日志记录，即logger.error("以开发者的立场对异常的简要描述", exp)，记录详细的异常信息；然后使用客户化的描述语言来描述异常信息，并用该信息初始化系统自定义的异常类，然后将其抛出。

          对于第二类异常，如果是在可以将异常描述信息呈献给用户的那一层捕获的，则直接将该异常的描述信息exp.getMessage9()呈献给用户，以给出错误提示（如在Action中，直接将msg显示到页面）；否则只需直接抛出即可

          我以前还见过在Action中抛出异常的，不知道这样做的目的是为何？难不成想让服务器来处理应用程序的经检查的异常？这让我想起了类似 main(String[] args) throws ...Exception {...} 的代码来。