建站
咨詢
售后
建站咨詢
新聞中心
對于一個(gè)Web應(yīng)用程序來說，出錯(cuò)是在所難免的，因此我們應(yīng)該未雨綢繆，為可能出現(xiàn)的錯(cuò)誤提供恰當(dāng)?shù)奶幚?。事?shí)上，良好的錯(cuò)誤處理機(jī)制正是衡量Web應(yīng)用程序好壞的一個(gè)重要標(biāo)準(zhǔn)。試想一下，當(dāng)用戶不小心在瀏覽器輸入了錯(cuò)誤的URL或者當(dāng)用戶提供了一些信息導(dǎo)致程序出錯(cuò)的時(shí)候，如果我們沒有對這些情況進(jìn)行處理，而是任由404或是500的錯(cuò)誤頁面甚至出錯(cuò)的堆棧信息呈現(xiàn)在用戶面前，這無疑會(huì)把一些用戶給嚇跑。所以，在我們開發(fā)Web應(yīng)用程序的時(shí)候，應(yīng)該對ASP.NET錯(cuò)誤處理機(jī)制有充分的了解。
成都創(chuàng)新互聯(lián)公司-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比靖邊網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式靖邊網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋靖邊地區(qū)。費(fèi)用合理售后完善，10多年實(shí)體公司更值得信賴。
讓我們回到ASP.NET上來，先提兩個(gè)問題讓大家思考一下：ASP.NET錯(cuò)誤處理機(jī)制有幾種呢？如果同時(shí)采用了幾種錯(cuò)誤處理機(jī)制，它們之間是否存在一定的優(yōu)先級呢？帶著這個(gè)問題，我們先來看一下我們最常見的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＞這個(gè)設(shè)置項(xiàng)，我想無需多言了，詳情可以參考MSDN的。第一種錯(cuò)誤處理機(jī)制——使用Web.Config的＜customErrors＞配置項(xiàng)應(yīng)該是大家最常用的。
接著，我們再看另外一個(gè)也很常用的文件：Global.asax。提到這個(gè)文件，大家想到了什么呢？對，就是跟兩大Web應(yīng)用程序?qū)ο螅ˋpplication、Session）相關(guān)的事件了。在這些事件當(dāng)中，有一個(gè)屬于Application范疇的與錯(cuò)誤相關(guān)的事件——Error，而對應(yīng)的事件處理方法就是Application_Error了。顧名思義，這個(gè)事件處理方法在應(yīng)用程序級別錯(cuò)誤發(fā)生的時(shí)候就會(huì)被調(diào)用，因此你可以在這個(gè)方法中添加代碼來對錯(cuò)誤進(jìn)行處理，如下所示：
- protected void Application_Error(object sender, EventArgs e) {
- Exception objErr = Server.GetLastError().GetBaseException();
- Response.Write("Error:" + objErr.Message);
- Server.ClearError();
- }
在這里，大家要注意最后一句代碼Server.ClearError()的使用，為什么要使用這句代碼呢？如果不用又會(huì)怎樣呢？在這里我又先賣個(gè)關(guān)子。好了，第二種錯(cuò)誤處理機(jī)制——使用Global.asax中的Application_Error事件處理方法也登臺(tái)亮相了。
以上這兩種錯(cuò)誤處理方法都可以說是全局性的，一個(gè)源自應(yīng)用程序配置文件，一個(gè)則是必須放在應(yīng)用程序根目錄下的Global.asax文件的事件處理方法。與全局相對的就是局部，所以我們很自然的就會(huì)想：有沒有應(yīng)用于局部——某個(gè)頁面的錯(cuò)誤處理機(jī)制呢？答案是“有的”，而且還有兩種————使用ErrorPage屬性以及使用Page_Error事件處理方法。對于第一種機(jī)制，你幾乎可以在任何時(shí)候設(shè)置ErrorPage屬性，從而確定頁面發(fā)生錯(cuò)誤的時(shí)候會(huì)重定向至哪個(gè)頁面；對于第二種機(jī)制而言，它與Application_Error事件處理方法是很類似的，只不過被觸發(fā)的時(shí)機(jī)不同而已。以下是具體的兩個(gè)例子：
- ＜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(); //同樣要注意這句代碼的使用
- }
至此，四種ASP.NET錯(cuò)誤處理機(jī)制已經(jīng)悉數(shù)登場，是時(shí)候給它們排個(gè)名次了。從優(yōu)先級高到低排序：Page_Error事件處理方法 ＞ ErrorPage屬性 ＞ Application_Error事件處理方法 ＞ ＜customErrors＞配置項(xiàng)。雖然排序是這樣，但是這個(gè)排序之間又有微妙的關(guān)系。首先，要讓ErrorPage屬性能夠發(fā)揮作用，＜customErrors＞配置項(xiàng)中的mode屬性必須設(shè)為"On"；其次，雖然Page_Error事件處理方法排在最前面，但是，如果少掉了Server.ClearError()方法的話，仍然會(huì)引發(fā)優(yōu)先級較低的錯(cuò)誤處理，這種情況對于Application_Error事件處理方法也是如此。順序是排好了，但是順序卻不是最重要的問題，甚至可以說是沒有太多意義的問題，因?yàn)樵诤芏嗲闆r下，你可能并不會(huì)混合使用這四種處理機(jī)制。我想，最重要的問題還是在如何選用這些錯(cuò)誤處理機(jī)制上。對于這個(gè)問題，希望有經(jīng)驗(yàn)的朋友能夠談?wù)効捶ā?/p>
好了，關(guān)于四種ASP.NET的錯(cuò)誤處理機(jī)制就介紹到這里，也該說說自己的一些感受了。ASP.NET的設(shè)計(jì)者確實(shí)站在開發(fā)者的角度作了周全的考慮，因此提供了多達(dá)四種的錯(cuò)誤處理機(jī)制供我們選用，這一點(diǎn)是值得稱道的。但是套用一句廣告詞——多則惑，我們也會(huì)被這么多的錯(cuò)誤處理機(jī)制弄得有些頭暈。對照J(rèn)2EE領(lǐng)域中的錯(cuò)誤處理，我們可以發(fā)現(xiàn)會(huì)相對簡單一些。首先是對應(yīng)＜customErrors＞的設(shè)置，我們也可以從J2EE項(xiàng)目最常用的web.xml文件中找到類似的配置項(xiàng)：＜errorPage＞；其次，在J2EE的領(lǐng)域中，Page并不是一個(gè)重要的實(shí)體而且事件驅(qū)動(dòng)模型也不是必需的，所以我還真的找不到與Application_Error和Page_Error方法對應(yīng)的處理機(jī)制；最后，在J2EE的領(lǐng)域中，更多強(qiáng)調(diào)的是Request和Response，一旦在邏輯處理中出現(xiàn)了錯(cuò)誤，我們可以很容易地通過RequestDispatcher將Request分發(fā)到相應(yīng)的錯(cuò)誤處理模塊中，事實(shí)上這是非常靈活的一種處理方式，有興趣的朋友不妨了解一下。
【編輯推薦】
- WCF初試,用JQuery實(shí)現(xiàn)loading的功能
- jQuery調(diào)用WCF服務(wù)傳遞JSON對象
- WCF的傳輸安全機(jī)制
- 詳解WCF中的變更處理：不可不知的最佳實(shí)踐
- 使用ASP.NET AJAX調(diào)用WCF服務(wù)項(xiàng)模板
文章名稱：ASP.NET的錯(cuò)誤處理機(jī)制
網(wǎng)頁網(wǎng)址：http://m.5511xx.com/article/ccddccs.html
