关于异常处理的建议

关于异常处理的建议
目的:方便的转换debug模式和发布模式,方便开发人员轻松找到错误原因,方便错误处理方式的更改,方便大家开发代码,减少try里套try的现象.

首先会有一个错误类,来处理错误.类的设计根据需求来定.webconfig里有个节点,来控制debug模式和发布模式.

第二,错误分类
A级 路径找不到,引用错误,服务错误,代码格式错误,这种错误用代码是无法捕获的,统一用Global.asax处理.
B级 直接导致一个页面无法显示的逻辑错误,如数据库连接不通,该错误用page.onError来处理.(关于B级错误一样可以按A级来处理,看需求)
C级 一般逻辑错误,即使错误,也不应该影响页面运行,用try catch处理.

具体要求:
1.写类库的时候
  统一把异常抛出.如果错误提示不够具体,可加补充说明.如
  try
 {
  抛个错误
        }
 catch(Exception ex)
       {
 string info="这里是A.B.C()方法报错,可能是***原因,可以和***联系";
        info=ex.Message+info;
 throw new  Exception(info);
       }
建议:这里的info字符串,可以写在另一个类里,把字符串统一写在一起,有利于扩展.(如代码与错误信息对应),团队操作可参考分布类.

2.在写页面的时候 
  要注意调用的方法哪些是B级错误,哪些是C级错误.
  比如我提交一条数据,其中需要上传一张图片,那么插入数据库错误就是B级,上传图片错误就是C级,上传图片方法就要用try,插入数据
  库的操作就不用try.
  同样,增加点击数的方法要try,显示数据方法不用try.
  页面写不写page.onError由需求决定.(一般不写,除非它要求这个页面这样处理错误,那个页面那样处理错误)
  catch的时候,把ex错误对象交给错误类来处理就行了,必要的时候要格式化下信息.
  总之,工作人员只需要判断下错误类型,把C级错误try起来就行了,其它的方法不用考虑.

3.写用户控件的时候
  一般性用户控件要求不管出什么错,不能影响页面运行,也就是说,如果像首页那样,很多用户控件,不能因为一个用户控件的错误,使整
  个首页看不到,所以大多数用户控件用C级处理方法来解决.(当然不是绝对,主要指小的栏目,要是像导航栏,操作菜单这样的用户控件,错
   了的话,整个页面是看不见的.)
4.调用方法时，必需要确定所传参数的有效性，方法本身不会对参数有效性进行验证。（为了必免出现未将对象实例化错误）

错误类设计原则
  根据webconfig里面的开关,决定是把传进来的参数抛出去,还是处理掉.处理方法看需求来定.