2010-04-08 73 views
4

這實際上並不適用於任何語言,但如果它很重要我在Visual Studio 2008中使用VB.NET。編程概念:拋出異常時應該做什麼?

我似乎無法找到任何有用的關於此主題的Google,但我想知道什麼是常見的做法,當一個異常被拋出並被捕獲,但由於它已被拋出應用程序無法繼續運行。

例如,當文件無法找到或文件被認爲已損壞時,我的例外是由我的FileLoader類拋出的。這個異常只在類中拋出,並沒有真正處理。如果檢測到錯誤,則拋出異常,並且拋出的任何函數基本上都會退出。

因此,在試圖創建該對象或調用其成員之一的代碼中,我使用Try ... Catch語句。但是,我想知道,當這個異常被捕獲時甚至應該做什麼?我的應用程序需要這些文件是完整的,如果它們不是,應用程序幾乎是無用的。到目前爲止,我只是彈出一個消息框告訴用戶他們是一個錯誤,並重新安裝。我還能做什麼,或者更好,在這些情況下常見的做法是什麼?

+0

相關/重複:http://stackoverflow.com/questions/242587/exception-handling-architecture – 2010-04-08 16:31:16

+0

我認爲你做正確的事情! – jjujuma 2010-04-08 16:35:04

+0

謝謝,當建議事項出現時,我沒有看到問題。很多好的答案在這裏! – Dooms101 2010-04-08 17:03:24

回答

3

恕我直言,有以下幾種類型的系統異常:

  1. 可恢復異常 - 這些地方的系統可能會遇到異常情況,但隨後可以默認的狀態下它可以繼續工作&會向用戶顯示一條消息,表明用戶可以選擇「繼續」,「重試」或「取消」該操作,該消息可以繼續使用默認選項。

  2. 不可恢復的例外 - 這些是系統無法繼續或有任何默認選項的情況。在這種情況下,需要用戶干預。所以系統顯示一條消息,與需要與選擇做或者「重試」或「取消」的操作

根據其異常類型的,你的情況下落入什麼正確的引導用戶,我希望這可能會有用。

0

在你特殊的情況下,這是唯一的出路。

在另一種情況下......它實際上取決於情況。

2

通常的做法是處理您可以的例外情況,並傳遞(使用可選日誌記錄)那些您不能使用的例外情況。如果你遇到了一個無法解決的問題,那麼再次嘗試就不會有幫助,正確的迴應就會停止。

2

在你的情況下,我認爲你正在做的是 - 用一個用戶友好的消息向用戶顯示錯誤,然後退出操作 - 正是你應該做的。

我傾向於將異常分爲兩類:您可以從中恢復的異常以及您無法從中恢復的異常。很明顯,如果你可以在沒有用戶知道有錯誤的情況下從異常中恢復,那麼這是最好的選擇。但在某些情況下,應用程序無法前進,您需要以某種方式取消當前操作。

您的聽起來不像是一個Web應用程序,但如果是這樣,那麼在發生意外錯誤時向開發人員發送電子郵件通常會很有幫助,以便開發人員可以進行適當的更改。

另請注意,很多框架都有一種方法來捕獲所有未捕獲的異常,而不將整個事件封裝在Try Catch塊中。例如,ASP.NET 3.5使用一個名爲Global.asax的類來捕獲所有異常。由於我們的應用程序是基於網絡的,因此這允許我們不希望通過該類路由的任何錯誤,並且我們可以向開發者發送錯誤電子郵件並向用戶顯示適當的錯誤頁面。雖然自然而然地,如果您希望在某個代碼塊中可能出現異常,那麼您可以在該塊附近放置Try-Catch,但對於所有其他代碼,這是有幫助的。

1

這個特定的'問題'沒有真正的普遍答案,但這裏有一些評論可能會幫助你。

  • 不要違揹你的抽象 - 如果你的代碼被稱爲在那個交易中的對象,但低於使用SQL數據存儲層,它不應該通過SQL異常讓。

  • 不要丟失信息 - 有時候,人們會發現異常並忽略它們,或者打印出類似「出錯的信息」。如果沒有足夠的詳細信息(無論是在日誌中還是在屏幕上),都無法確定問題發生的位置/時間,並且可能需要花費相當長時間的調試時間。

  • 異常層次結構 - 這可能並不適用於所有的語言,但如果你可以按層次結構的異常,並能抓住他們的樹,而不是隻是一個單一的一個,大量的代碼變得很乾淨。

你的方法在你的情況聽起來不錯。通知用戶發生致命錯誤並中止執行。從Sunny的優秀答案中借用它是不可恢復的,因此您必須要求用戶進行干預。就個人而言,如果可能的話,我寧願有一個警告並恢復爲默認值或內部值,而不是崩潰並要求重新安裝。

0

我經常用我開發的內部工具遇到這種情況。我通常會像你一樣處理它;向用戶顯示錯誤消息,並讓他們重試或退出。

相關問題