一、避免throw中将异常堆栈信息吃掉
二、处理未捕获异常和多线程异常
三、避免在调用栈较低位置记录异常
最适合进行异常记录和报告的是应用程序的最上层,这通常是UI层。假设存在这样的一个应用程序,它的BLL层,即可能被一个Winform窗口程序调用,也可能被一个控制台应用程序调用,那么如果要在BLL模块向管理员报告异常的时候,你不知该使用MessageBox方法还是Console.Write方法。
如果异常在调用栈的较低位置被记录或报告,且还存在被包装后重新抛出的情况,这就会让记录重复出现。
四、推荐总是使用FCL异常
也即慎用自定义异常。需要自定义异常的理由如下:
1、方便调试,通过抛出一个我们自己定义的异常类型实例,我们可以使捕获代码精确地知道所发生的事情,并以合适的方式进行恢复。
2、逻辑包装,自定义异常可包装多个其它异常,然后抛出一个业务异常。
3、方便调用者编码,在编写自己的类库或者业务层代码的时候,自定义异常可以让调用方更方便处理业务异常逻辑。如保存数据失败,可以分成两个异常"数据库连接失败。"、"网络异常。"
4、引入新异常类,使程序员能够根据异常类在代码中采取不同的操作。
五、不要再从System.ApplicationExcetipn这个基类派生异常
微软自己也已经修正这一点,当前的建议是:从System.Exception或其它常见基本异常之一派生异常。
事实上,现在如果你在Visual studio中输入Excetion,然后使用快捷键tab,vs会自动给你创建一个继承自System.Exception的自定义异常类。
六、避免在finally撰写无效代码
需要先提出一个问题,即:是否存在一种打破try-finally执行顺序的情况。
答案是:没有(除非应用程序本身因为某些很少出现的特殊情况在try块中退出)。
你应该始终认为finally内代码会在方法return之前被执行,哪怕return是在try块中。
二、处理未捕获异常和多线程异常
三、避免在调用栈较低位置记录异常
最适合进行异常记录和报告的是应用程序的最上层,这通常是UI层。假设存在这样的一个应用程序,它的BLL层,即可能被一个Winform窗口程序调用,也可能被一个控制台应用程序调用,那么如果要在BLL模块向管理员报告异常的时候,你不知该使用MessageBox方法还是Console.Write方法。
如果异常在调用栈的较低位置被记录或报告,且还存在被包装后重新抛出的情况,这就会让记录重复出现。
四、推荐总是使用FCL异常
也即慎用自定义异常。需要自定义异常的理由如下:
1、方便调试,通过抛出一个我们自己定义的异常类型实例,我们可以使捕获代码精确地知道所发生的事情,并以合适的方式进行恢复。
2、逻辑包装,自定义异常可包装多个其它异常,然后抛出一个业务异常。
3、方便调用者编码,在编写自己的类库或者业务层代码的时候,自定义异常可以让调用方更方便处理业务异常逻辑。如保存数据失败,可以分成两个异常"数据库连接失败。"、"网络异常。"
4、引入新异常类,使程序员能够根据异常类在代码中采取不同的操作。
五、不要再从System.ApplicationExcetipn这个基类派生异常
微软自己也已经修正这一点,当前的建议是:从System.Exception或其它常见基本异常之一派生异常。
事实上,现在如果你在Visual studio中输入Excetion,然后使用快捷键tab,vs会自动给你创建一个继承自System.Exception的自定义异常类。
六、避免在finally撰写无效代码
需要先提出一个问题,即:是否存在一种打破try-finally执行顺序的情况。
答案是:没有(除非应用程序本身因为某些很少出现的特殊情况在try块中退出)。
你应该始终认为finally内代码会在方法return之前被执行,哪怕return是在try块中。