ASP.NET中异常处理的注意事项

最新推荐文章于 2024-11-02 11:32:21 发布

njit_peiyuan

最新推荐文章于 2024-11-02 11:32:21 发布

阅读量116

点赞数

文章标签： ui c# 数据库

一、ASP.NET中需要引发异常的四类情况

1、如果运行代码后，造成内存泄漏、资源不可用或应用程序状态不可恢复，则引发异常。Console这个类中，有很多类似这样的代码：

if ((value < 1) || (value > 100))
{
throw new ArgumentOutOfRangeException("value", value, Environment.GetResourceString("ArgumentOutOfRange_CursorSize"));
}

2、在捕获异常的时候，如果需要包装一些更有用的信息，则引发异常。这类异常的引发在UI层特别有用。系统引发的异常所带的Message往往更倾向于技术性的描述，而在UI层，异常的用户很可能是最终用户。如果我们需要将异常的Message信息呈现给最终用户，更好的做法是包装异常，然后引发一个含有友好信息的新异常。

3、如果底层异常在高层操作的上下文中没有意义，则可以考虑捕获这些底层异常，并引发新的有意义的异常。如将一个InvalidCastException引发为新的ArgumentException。

4、捕获底层API错误代码，并抛出。Console为我们封装了调用windows api返回的错误代码，而让代码引发一个新的异常。

二、ASP.NET系统自带的异常类

1、Exception 所有异常对象的基类
2、SystemException 运行时产生的所有错误的基类
3、IndexOutOfRangeException 当一个数组的下标超出范围时运行时引发
4、NullReferenceException 当一个空对象被引用时运行时引发

5、InvalidOperationException 当对方法的调用对对象的当前状态无效时，由某些方法引发
6、ArgumentException 所有参数异常的基类
7、ArgumentNullException 在参数为空（不允许）的情况下，由方法引发
8、ArgumentOutOfRangeException 当参数不在一个给定范围之内时，由方法引发

9、InteropException 目标在或发生在CLR外面环境中的异常的基类
10、ComException 包含COM 类的HRESULT信息的异常
11、SEHException 封装win32 结构异常处理信息的异常

三、ASP.NET中异常处理注意事项

1、避免在finally内撰写无效代码

你应该始终认为finally内代码会在方法return之前被执行，哪怕return是在try块中。但，需要区分引用类型变量和值类型变量在finally中会导致不同结果。

例如

C# 代码复制

private static int TestIntReturnInTry() { int i; try { return i = 1; } finally { i = 2; Console.WriteLine("\\t将int结果改为2，finally执行完毕"); } }

它返回的将是1。代码中，i=2实际上是一段无效代码，如果编译采用Release模式，编译器会直接将i=2删除，它不会为其生成对应的IL代码。

但是：

C# 代码复制

       static User TestUserReturnInTry()
{ User user = new User() { Name = "Mike", BirthDay = new DateTime(2010, 1, 1) }; try { return user; } finally { user.Name = "Rose"; user.BirthDay = new DateTime(2010, 2, 2); Console.WriteLine("\\t将user.Name改为Rose"); } }

TestUserReturnInTry方法返回的User中，Name的值已经改变为Rose了。

2、避免嵌套异常　

应该允许异常在调用堆栈中往上传播，不要过多使用catch，然后再throw。无故地嵌套异常是我们要极力避免的。

3、避免“吃掉”异常

避免“吃掉”异常，并不是说不应该“吃掉”异常，而是这里面有个重要原则：该异常可悲预见，并且通常情况它不能算是一个Bug。

想象你正在对上万份文件进行解密，这些文件来自不同的客户端，很有可能存在文件倍破坏的现象，你的目标就是要讲解密出来的数据插入数据库。这个时候，你不得不忽略那些解密失败的问题，让这个过程进行下去。当然，记录日志是必要的，因为后期你可能会倍解密失败的文件做统一的处理。

另外一种情况，可能连记录日志都不需要。在对上千个受控端进行控制的分布式系统中，控制端需要发送心跳数据来判断受控端的在线情况。通常的做法是维护一个信号量，如果在一个可接受的阻滞时间如（如500ms）心跳数据发送失败，那么控制端线程将不会收到信号，即可以判断受控端的断线状态。在这种情况下，对每次SocketException进行记录，通常也是没有意义的。

如果你不知道如何处理某个异常，那么千万不要“吃掉”异常，如果你一不小“吃掉”了一个本该网上传递的异常，那么，这里可能诞生一个BUg，而且，解决它会很费周折。

4、避免在调用栈较低位置记录异常

最适合进行异常记录和报告的是应用程序的最上层，这通常是UI层。假设存在这样的一个应用程序，它的BLL层，即可能被一个Winform窗口程序调用，也可能被一个控制台应用程序调用，那么如果要在BLL模块向管理员报告异常的时候，你不知该使用MessageBox方法还是Console.Write方法。

如果异常在调用栈的较低位置被记录或报告，且还存在被包装后重新抛出的情况，这就会让记录重复出现。

5、不要再从System.ApplicationExcetipn这个基类派生异常

微软自己也已经修正这一点，当前的建议是：从System.Exception或其它常见基本异常之一派生异常。事实上，现在如果你在Visual studio中输入Excetion，然后使用快捷键tab，vs会自动给你创建一个继承自System.Exception的自定义异常类

四、ASP.NET中异常处理的其它建议

1、当引发异常时，要提供有意义的文本。
2、要引发异常仅当条件是真正异常；也就是当一个正常的返回值不满足时。
3、如果你的方法或属性被传递一个坏参数，要引发一个ArgumentException异常。

4、当调用操作不适合对象的当前状态时，要引发一个InvalidOperationException异常。
5、要引发最适合的异常。
6、要使用链接异常，它们允许你跟踪异常树。

7、不要为正常或预期的错误使用异常。
8、不要为流程的正常控制使用异常。
9、不要在方法中引发NullReferenceException或IndexOutOfRangeException异常。