Global.asax中的Application_Error真的是處理錯誤的方法嗎？

Question

有一天我出現在採訪中，面試官問我global.asax的目的是什麼。我說這是爲了捕獲像Session_Start等特定事件。然後他說你如何在代碼中進行異常處理？我說我們在try catch塊中包裝這些語句。他然後說，你會爲你的代碼中的所有按鈕點擊事件做這件事嗎？這是非常乏味和重複的。 OOP在這裏出現在哪裏？他說你應該總是在Global.asax中的Application_Error中發現錯誤。我說OOP並沒有說你應該在這個事件中發現所有的錯誤。我們應該總是抓住特定的例外，並且應該在那些各自的處理者中。在面試時我們相當吵架，我直截了當地在他臉上說我不同意你的看法。

你能告訴我你是如何處理服務器端的異常？

感謝提前:)

Answer 1

我發現的簡短答案是，如果您想保留這份工作，即使您不同意它，您也會按照指示編碼的方式進行編碼。

但是，如果您只捕獲Global.asax中的錯誤，那麼您將失去本地變量調試和優雅的錯誤處理。 Global.asax中處理的錯誤通常不會優雅地失敗。

我通常會捕獲Global.asax中的任何未處理的錯誤，但對我來說，只有在這裏處理這個問題就像沒有剎車，因爲它有安全氣囊。 （是的，我愛的隱喻）

Answer 2

一種選擇是讓所有在您的網站的網頁的擴展，其處理System.Web.UI.TemplateControl的錯誤事件Page類。

如果您無法讓網站上的所有網頁擴展一個通用基類，Application_Error會很有用。

Answer 3

的關鍵，這一切的是預計和意外例外之間的區別。在編寫代碼時，您應該明確地捕獲您期望可能發生的異常。

完美的例子是除法。你用分母除分子。你知道除以零會引發異常。此時，您可以捕獲預期的異常，以在遇到異常（基本上由您的需求決定）之前處理或顯式拋出異常。 意想不到的例外發揮作用，如果你什麼都不做。

由於大多數軟件編寫方式的性質，未處理的異常對於用戶體驗來說很差，並且不幸的是，更常見的一種異常。它們是由頻繁的代碼流失，缺乏對需求的理解，對更廣泛的系統的有限知識以及僅僅是懶惰所引起的。通常，遇到這些問題時，它們會導致軟件操作方面的突然變化。

全球異常處理程序的目的是/正常恢復或通知用戶在收集儘可能多的有價值信息時出現了問題./就我個人而言，我發現這些異常應以有意義的方式記錄下來，並且儘快解決。如果遇到這種情況，很可能是預期條件未被執行或處理，或者代碼中存在導致應用程序進入無效狀態的邏輯問題。

正確使用，全局異常處理程序是一個很好的安全網絡，可用於幫助提高代碼質量。涉及的風險一般來自於僅依賴全局異常處理程序，或者忽略對所報告的內容採取行動。

Answer 4

你應該只會發現錯誤，當你可以做些什麼關於他們（不只是登錄他們），這是相當罕見的。

例如，它的合理趕上SqlExceptions重試死鎖：

catch(SqlException exception) { 
    if (exception.Number == 1205) 
     // call retry code 
    else 
     throw; 
} 

這是不合理地抓住每一個例外，在你的頁面處理方法，如果你只是要記錄這些異常和顯示通用的'aw snap'消息。將該代碼放在一個地方：Application_Error。

爲了解決問題，你可以預期（如除以零錯誤），你應該避免在首位無效輸入或處理條件之前產生的異常：

// Make sure the exception never happens and provide meaningful feedback 
if (divisor == 0) { 
    txtErrorMessage.Text = "Enter a value greater than zero."; 
    return; 
} 

txtQuotient.Text = dividend/divisor;