此前，我定義了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掉。
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
