ASP.net錯誤處理(錯誤跳轉頁 webconfig)分類：
學習當中2012-02-23 13:12 281人閱讀
評論(0)
舉報asp.netapplicationredirectexceptionobject瀏覽器ASP.net錯誤處理(錯誤跳轉頁 webconfig)
2008-06-19 13:30
使用定制錯誤頁面
雖然我們發(fā)送給用戶的公用錯誤信息是安全的，就是說它不會威脅到應用程序的秘密，但是這樣的信息并不好看。也許你希望用戶永遠也看不到這樣的信息。相反，當處理請求的過程中，如果發(fā)生了一個為處理的錯誤，你希望能夠顯示自己的“定制錯誤頁面”，顯示出自己的品牌以及特定的錯誤信息。
向ASP.NET 應用程序中增加定制錯誤信息非常容易。首先，編寫自己的 web頁面，它可以是任何類型的文件：.htm，.aspx，.asp，等等。然后在應用程序的config.web文件中修改配置信息，讓它指向這個文件。
舉例說明，以下這個配置信息說明在發(fā)生了任何未能預定處理錯誤的情況下，瀏覽器都應該被重定向到“ErrorPage.aspx”頁面：
<configuration> <customerrors mode="remoteonly" defaultredirect="ErrorPage.aspx" /> </configuration>
<customerrors>標記中的“defaultredirect”屬性定義了在發(fā)生錯誤的情況下，用戶將被重定向到的“默認”頁面?；蛘撸部梢愿鶕?jù)響應的http代碼狀態(tài)，重定向到其它的頁面來覆蓋這個默認值。例如：重定向到一個特殊的“未找到文件”錯誤頁面、“非法訪問”錯誤頁面、“服務器沖突”錯誤頁面等等。
舉例說明，以下的配置信息覆蓋3個特定的http 狀態(tài)代碼，所有其它錯誤都返回到一個默認頁面：
<customerrors defaultredirect="http://anotherhost/error.aspx" mode="remoteonly"> <error statuscode="500" redirect="http:/anotherhost/pages/callsupport.html" /> <error statuscode="404" redirect="http:/anotherhost/pages/adminmessage.html" /> <error statuscode="403" redirect="http:/anotherhost/pages/noaccess.html" /> </customerrors>
在定制錯誤頁面上有一件事我們已經(jīng)遇到過，那就是雖然它們對于已經(jīng)完成的情況非常有用，然而在開發(fā)過程中卻非常難以對付。因為你預想到在開發(fā)過程中會有bug，并且當你發(fā)現(xiàn)的時候，真的希望看到實際的錯誤信息跟蹤。為了解決這個問題，<customerrors>標記支持一個有3個值的“mode”屬性：
“on”：意思是總是發(fā)出定制錯誤頁面；
“off”：意思是從不發(fā)出定制錯誤頁面（你總是看到原始的錯誤信息）；
“remoteonly”：意思是只有當遠程瀏覽器點擊站點時才發(fā)出定制錯誤頁面（而在實際機器上點擊站點的開發(fā)人員看到的是詳細的錯誤信息）。
二,在Global.asax文件中添加應用出錯代碼，寫入系統(tǒng)日志文件
Code
protected void Application_Error(Object sender, EventArgs e)
{
Exception LastError = Server.GetLastError();
String ErrMessage = LastError.ToString();
String LogName = "MyLog";
String Message = "Url " + Request.Path + " Error: " + ErrMessage;
// Create Event Log if It Doesn't Exist
if (!EventLog.SourceExists(LogName))
{
EventLog.CreateEventSource(LogName, LogName);
}
EventLog Log = new EventLog();
Log.Source = LogName;
//These are the five options that will display a different icon.
Log.WriteEntry(Message, EventLogEntryType.Information, 1);
Log.WriteEntry(Message, EventLogEntryType.Error, 2);
Log.WriteEntry(Message, EventLogEntryType.Warning, 3);
Log.WriteEntry(Message, EventLogEntryType.SuccessAudit, 4);
Log.WriteEntry(Message, EventLogEntryType.FailureAudit, 5);
}
=========================================
對于一個Web應用程序來說，出錯是在所難免的，因此我們應該未雨綢繆，為可能出現(xiàn)的錯誤提供恰當?shù)奶幚?。事實上，良好的錯誤處理機制正是衡量Web應用程序好壞的一個重要標準。試想一下，當用戶不小心在瀏覽器輸入了錯誤的URL或者當用戶提供了一些信息導致程序出錯的時候，如果我們沒有對這些情況進行處理，而是任由404或是500的錯誤頁面甚至出錯的堆棧信息呈現(xiàn)在用戶面前，這無疑會把一些用戶給嚇跑。所以，在我們開發(fā)Web應用程序的時候，應該對錯誤處理機制有充分的了解。
讓我們回到ASP.NET上來，先提兩個問題讓大家思考一下：ASP.NET為我們提供了幾種錯誤處理機制呢？如果同時采用了幾種錯誤處理機制，它們之間是否存在一定的優(yōu)先級呢？帶著這個問題，我們先來看一下我們最常見的Web.Config文件：
＜?xml version="1.0"?＞
＜configuration＞
＜system.web＞
＜customErrors mode="On" defaultRedirect="GenericErrorPage.htm"＞
＜error statusCode="403" redirect="Error403.htm" /＞
＜error statusCode="404" redirect="Error404.htm" /＞
＜/customErrors＞
＜/system.web＞
＜/configuration＞
對于＜customErrors＞這個設置項，我想無需多言了，詳情可以參考MSDN的。第一種錯誤處理機制——使用Web.Config的＜customErrors＞配置項應該是大家最常用的。
接著，我們再看另外一個也很常用的文件：Global.asax。提到這個文件，大家想到了什么呢？對，就是跟兩大Web應用程序對象（Application、Session）相關的事件了。在這些事件當中，有一個屬于Application范疇的與錯誤相關的事件——Error，而對應的事件處理方法就是Application_Error了。顧名思義，這個事件處理方法在應用程序級別錯誤發(fā)生的時候就會被調(diào)用，因此你可以在這個方法中添加代碼來對錯誤進行處理，如下所示：
protected void Application_Error(object sender, EventArgs e) {
Exception objErr = Server.GetLastError().GetBaseException();
Response.Write("Error:" + objErr.Message);
Server.ClearError();
}
在這里，大家要注意最后一句代碼Server.ClearError()的使用，為什么要使用這句代碼呢？如果不用又會怎樣呢？在這里我又先賣個關子。好了，第二種錯誤處理機制——使用Global.asax中的Application_Error事件處理方法也登臺亮相了。
以上這兩種錯誤處理方法都可以說是全局性的，一個源自應用程序配置文件，一個則是必須放在應用程序根目錄下的Global.asax文件的事件處理方法。與全局相對的就是局部，所以我們很自然的就會想：有沒有應用于局部——某個頁面的錯誤處理機制呢？答案是“有的”，而且還有兩種————使用ErrorPage屬性以及使用Page_Error事件處理方法。對于第一種機制，你幾乎可以在任何時候設置ErrorPage屬性，從而確定頁面發(fā)生錯誤的時候會重定向至哪個頁面；對于第二種機制而言，它與Application_Error事件處理方法是很類似的，只不過被觸發(fā)的時機不同而已。以下是具體的兩個例子：
＜script language="C#" runat="server"＞
protected void Page_Load(object sender, EventArgs e) {
this.ErrorPage = "ErrorPage.htm";
}
＜/script＞
protected void Page_Error(object sender, EventArgs e) {
Exception objErr = Server.GetLastError().GetBaseException();
Response.Write("Error:" + objErr.Message);
Server.ClearError(); //同樣要注意這句代碼的使用
}
至此，四種錯誤處理機制已經(jīng)悉數(shù)登場，是時候給它們排個名次了。從優(yōu)先級高到低排序：Page_Error事件處理方法 ＞ ErrorPage屬性 ＞ Application_Error事件處理方法 ＞ ＜customErrors＞配置項。雖然排序是這樣，但是這個排序之間又有微妙的關系。首先，要讓ErrorPage屬性能夠發(fā)揮作用，＜customErrors＞配置項中的mode屬性必須設為"On"；其次，雖然Page_Error事件處理方法排在最前面，但是，如果少掉了Server.ClearError()方法的話，仍然會引發(fā)優(yōu)先級較低的錯誤處理，這種情況對于Application_Error事件處理方法也是如此。順序是排好了，但是順序卻不是最重要的問題，甚至可以說是沒有太多意義的問題，因為在很多情況下，你可能并不會混合使用這四種處理機制。我想，最重要的問題還是在如何選用這些錯誤處理機制上。對于這個問題，希望有經(jīng)驗的朋友能夠談談看法。
好了，關于ASP.NET的四種錯誤處理機制就介紹到這里，也該說說自己的一些感受了。ASP.NET的設計者確實站在開發(fā)者的角度作了周全的考慮，因此提供了多達四種的錯誤處理機制供我們選用，這一點是值得稱道的。但是套用一句廣告詞——多則惑，我們也會被這么多的錯誤處理機制弄得有些頭暈。對照J2EE領域中的錯誤處理，我們可以發(fā)現(xiàn)會相對簡單一些。首先是對應＜customErrors＞的設置，我們也可以從J2EE項目最常用的web.xml文件中找到類似的配置項：＜errorPage＞；其次，在J2EE的領域中，Page并不是一個重要的實體而且事件驅動模型也不是必需的，所以我還真的找不到與Application_Error和Page_Error方法對應的處理機制；最后，在J2EE的領域中，更多強調(diào)的是Request和Response，一旦在邏輯處理中出現(xiàn)了錯誤，我們可以很容易地通過RequestDispatcher將Request分發(fā)到相應的錯誤處理模塊中，事實上這是非常靈活的一種處理方式
分享到：
上一篇：
repeater 排序下一篇：
文本框js 驗證
