三种编程中的典型错误类型
搞开发的朋友都清楚，代码跑起来碰到错误是常事。不过，哪些错误最让人头疼？一般来说，可以归为三类。
编译错误
这种错误通常是语法层面的问题，比如少了个分号或者括号不匹配。一旦出现，ASP引擎就会直接罢工，程序连跑都跑不起来，直接给你亮红灯。
运行错误
这种错误就“狡猾”一些了，它发生在程序执行过程中。打个比方，你想给一个变量赋值，结果数值超出了这个变量类型的允许范围，系统就会当场“报错”。这类错误才是我们需要重点防范的对象。
逻辑错误
这恐怕是所有错误里最难缠的一类。它本质上是一种结构或流程上的设计缺陷，计算机本身识别不了，代码可能照样能运行，但得出的结果却和预想的差了十万八千里。抓出这种“虫子”，只能靠开发者自己，必须把代码逻辑从头到尾捋个明明白白。
编译错误通常会和逻辑错误一块儿出现，而且系统会明确提示，所以相对好办。我们真正要担心的，其实是那些会中断程序、并给用户扔出一堆“天书”般提示的运行错误。这不仅影响体验，也显得咱们的工作不够专业。
如何优雅地处理运行错误？
那么，运行错误该怎么应对呢？ASP本身提供的错误处理工具其实不多，核心就一个命令：On Error Resume Next（这里给新手提个醒：ASP只有这一种写法，没有 On Error Resume Goto）。
如果不使用这个语句，任何运行时错误都会导致程序崩溃，并把一段冰冷的技术错误代码直接丢给用户看。比如下面这种样子：
Microsoft OLE DB Provider for ODBC Drivers error 80004005 [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified /test.asp, line 60
而当你在程序开头加上 On Error Resume Next 后，情况就不同了。即使遇到错误，程序也会“忽略”它，继续执行下一行。这样一来，用户确实看不到错误信息了，程序也能完整跑完。但这也带来了新问题：如果程序执行结果不对，你很难快速定位到底是哪一步出了岔子。所以，必须在代码的关键位置，主动增加检查错误的逻辑。
构建有效的错误处理机制
在ASP开发中，一个比较稳妥的做法是在程序末尾统一进行错误处理。同时，强烈建议为每个ASP页面开启缓冲区（Response.Buffer = True）。这样，一旦发生错误，可以清空已经生成的页面内容，转而向用户展示一个更友好的定制化错误提示页，而不是暴露系统信息。
下面是一个基础的错误处理示例：
<%@ LANGUAGE="VBScript" %> <% '设置buffer为True Response.Buffer = True '开始错误处理 On Error Resume Next %> <% '错误处理 If Err.Number <> 0 Then '清除页面 Response.Clear '显示错误信息给用户 %>An error occurred in the execution of this ASP page
Please report the following information to the support deskPage Error Object
<%End If%>
错误 Number： <%= Err.Number %>
错误信息： <%= Err.Description %>
出错文件： <%= Err.Source %>
出错行： <%= Err.Line %>
可以看到，通过 On Error Resume Next 配合主动检查 Err.Number，我们能掌控错误，而不是被错误牵着鼻子走。
错误处理与数据库操作的协同
把错误处理机制融入到数据库操作中，情况会复杂一些。举个例子，一个程序里有多条指令要向数据库插入记录，如果插入动作放在最后执行，而程序前半部分已经出错了，那麻烦就大了。由于 On Error Resume Next 的“宽容”策略，即便前面有错，程序依然会把无效的数据提交到数据库里。
要避免这种情况，就得在关键节点前加上“安全检查”。正确的做法应该像这样：
If Err.Number = 0 And objConnection.Errors.Count = 0 Then '这里才能执行语句，因为没有错误 Set rstResults = dbData.Execute(txtSql) End If
更高级的错误处理策略
当然，你也可以构建更强大的错误处理程序，捕获并展示更详尽的信息，尤其是数据库操作中的错误。下面的例子能同时处理页面级和数据库级的错误，让问题排查一目了然。
<% If Err.Number <> 0 Then Response.Clear Select Case Err.Number Case 8 '指定错误的Number '在这里处理自定义错误 Case Else '一般错误 If IsObject(objConnection) Then If objConnection.Errors.Count > 0 Then %> Database Connection Object <% For intLoop = 0 To objConnection.Errors.Count - 1 %> Error No: <%= objConnection.Errors(intLoop).Number %>
Description: <%= objConnection.Errors(intLoop).Description %>
Source: <%= objConnection.Errors(intLoop).Source %>
SQLState: <%= objConnection.Errors(intLoop).SQLState %>
NativeError: <%= objConnection.Errors(intLoop).NativeError %><% Next End If End If If Err.Number <> 0 Then %> Page Error Object
Error Number <%= Err.Number %>
Error Description <%= Err.Description %>
Source <%= Err.Source %>
LineNumber <%= Err.Line %><% End If End Select End If %>
这个例子帮我们一举解决了数据库和页面中的多种潜在问题，相当实用。同时，其中的 Select Case 语句结构也为我们预留了处理特定自定义错误的空间。
特别注意：Redirect 与错误处理的冲突
有一点特别容易被忽略，就是我们常用的 Response.Redirect 方法。如果在页面中使用了重定向，那么之前准备的错误处理逻辑很可能会失效。因此，在跳转之前，必须再进行一次错误检查：
If Err.Number = 0 And objConnection.Errors.Count = 0 Then Response.Clear Response.RedirectEnd If
让代码更整洁：最佳实践总结
最后，分享几个能让代码更清晰、更易维护的习惯：
模块化错误处理：将错误处理的核心代码封装到一个独立的包含文件（include file）中。这样，所有页面都能方便地调用，未来修改和维护也只需改动一处。
善用 On Error Resume Next：在声明脚本语言后，尽早（程序最上方）加入此语句，为整个页面启用错误处理。
执行前检查：在运行任何重要的SQL语句之前，务必先进行错误检查。
跳转前确认：如同前面提到的，在使用 Response.Redirect 转向之前，也要确保没有未处理的错误。
合理组织文件：把那个包含错误处理逻辑的文件，稳妥地放在所有代码的最上方，确保它能第一时间发挥作用。
遵循以上几点，你的ASP程序在面对错误时，就能表现得更加稳健和专业了。
