其实,正如Rod Johnson所说,一般数据库异常的话,我们确实只能是无能为力,只能在业务层或者Action层进行处理。如果把异常定义为运行时异常的话,那就不用被编译器检查,如果架构中没有对异常处理给出严格的处理规则,那么既又可能我们这个异常就会造成程序整个报错。
这样,显然不是我们想看到的事情。
那么,就需要我们在架构中定义出我们的异常处理规则,对于处理数据库的异常,我们给出什么样的处理;其它的异常,给出什么样的处理。其实,确实是应该在项目中构建这样的异常。
比如我经常遇到的:按照模块分,那个模块出对应模块的异常;按照类型分,哪种类型出什么样的异常:比如说上传文件的异常;数据库访问的异常;数据输入异常;以及其它等等异常。
将它定义好了,然后在Action层进行统计处理,如果是A异常,那么跳到A的出错页面;如果是B异常,则跳到B的页面。这样程序中省去了很多异常处理代码,架构更干净了。真是何乐而不为呢:)
今天下午在向页面显示异常信息的时候,整了好半天也没有将自己想要的异常的格式在页面上输出来。明明debug出来的是这样的,怎么到页面上显示就成那样的呢?到后来,查看页面源代码才发现因为输出的异常信息中包含的标签被浏览器当成标签处理了。
比如这个
<reopenCount>标签就被浏览器给识别为标签的。这样,需要将<改成< >改成>就可以了
这么一个简单的问题,困扰了我1个半小时,实在是搞笑。不做页面一段时间,居然这个问题都要搞这么久,郁闷之余,还有点惊喜。代码规范和代码评审通过了……
这样,显然不是我们想看到的事情。
那么,就需要我们在架构中定义出我们的异常处理规则,对于处理数据库的异常,我们给出什么样的处理;其它的异常,给出什么样的处理。其实,确实是应该在项目中构建这样的异常。
比如我经常遇到的:按照模块分,那个模块出对应模块的异常;按照类型分,哪种类型出什么样的异常:比如说上传文件的异常;数据库访问的异常;数据输入异常;以及其它等等异常。
将它定义好了,然后在Action层进行统计处理,如果是A异常,那么跳到A的出错页面;如果是B异常,则跳到B的页面。这样程序中省去了很多异常处理代码,架构更干净了。真是何乐而不为呢:)
今天下午在向页面显示异常信息的时候,整了好半天也没有将自己想要的异常的格式在页面上输出来。明明debug出来的是这样的,怎么到页面上显示就成那样的呢?到后来,查看页面源代码才发现因为输出的异常信息中包含的标签被浏览器当成标签处理了。
xml 代码
- <reopenCount>hahaha</reopenCount>
这么一个简单的问题,困扰了我1个半小时,实在是搞笑。不做页面一段时间,居然这个问题都要搞这么久,郁闷之余,还有点惊喜。代码规范和代码评审通过了……