此前，我定义了web.config的customError 段， 使系统中一旦发生异常， 就转到自定义的错误页面， 但是这样做有一个很严重的问题， 就是无法看到异常的信息， 最近我越来越觉得无法忍受这一点， 于是换了一种做法， 在global.asax中， 自定义Application_Error 事件，在这里可以得到异常的信息， 然后把它传递给错误页面， 最终用Server.Transfer 方法转到错误页面.
之所以用Server.Transfer 不仅是出于效率的考虑， 而且因为它不显示错误页面的url，显示的仍然是抛出异常的页面的url， 这一点很好， 而且在开发时可以直接刷新来更新原页面. 但是不幸的是它并不总是有效， 在某些情况下， 抛出异常的页面并没有定向到错误页面， 而是显示一个脚本错误:
Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled.
Details: Error parsing near '
<!DOCTYPE html P'.
这个错误超出了我的理解范围，于是我求助于Google，发现了这样一篇文章:No, you cannot call Server.Transfer on an ASP.NET AJAX enabled page，这一来就明白了，没有出错的页面是没有使用UpdatePanel的，而凡是使用了UpdatePanel的页面都会报这个错。错误的原因：部分回发总是由客户端的PageRequestManager 对象引起的，它等待服务器给出的答复，并动态刷新页面，但是使用了Server.Transfer以后，服务器会发回另一个页面的内容，这不是PageRequestManager 认为它应该看到的东西，所以就会产生Parse错误，进而当然Server.Transfer也就失效了。
解决的办法很简单，用Response.Redirect。
顺便说一句的是，如果像我一样在Application_Error中处理异常并转到一个固定的错误页面，则Application_Error事件中必须对错误页面做特殊的处理，因为一旦这个错误页面自己产生了异常，就会形成死循环，这个死循环会快速地向IIS日志中写入大量的垃圾数据，直至塞满硬盘而使整个服务器down掉。