ASP错误捕获的几种常规处理方式

三种编程中的典型错误类型

搞开发的朋友都清楚，代码跑起来碰到错误是常事。不过，哪些错误最让人头疼？一般来说，可以归为三类。

编译错误

这种错误通常是语法层面的问题，比如少了个分号或者括号不匹配。一旦出现，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 desk

Page Error Object

错误 Number： <%= Err.Number %>

错误信息： <%= Err.Description %>

出错文件： <%= Err.Source %>

出错行： <%= Err.Line %>




<%End If%>

可以看到，通过 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.Redirect 
End If

让代码更整洁：最佳实践总结

最后，分享几个能让代码更清晰、更易维护的习惯：

模块化错误处理：将错误处理的核心代码封装到一个独立的包含文件（include file）中。这样，所有页面都能方便地调用，未来修改和维护也只需改动一处。

善用 On Error Resume Next：在声明脚本语言后，尽早（程序最上方）加入此语句，为整个页面启用错误处理。

执行前检查：在运行任何重要的SQL语句之前，务必先进行错误检查。

跳转前确认：如同前面提到的，在使用 Response.Redirect 转向之前，也要确保没有未处理的错误。

合理组织文件：把那个包含错误处理逻辑的文件，稳妥地放在所有代码的最上方，确保它能第一时间发挥作用。

遵循以上几点，你的ASP程序在面对错误时，就能表现得更加稳健和专业了。