2010-07-21 80 views
1

我不問如何在Ruby中使用begin..rescue語句。相反,我問你如何找出值得擔憂的事情。我知道一些鐵桿人可能會通過文檔/代碼來查找每一個可能的錯誤,並且有代碼能夠優雅地處理所有的情況。但是如果你不寫一些「關鍵任務」,那可能會變得太過分了。如何通過適當的異常處理使你的Ruby腳本健壯

那麼你怎麼知道要注意什麼錯誤?我通常只是運行我的代碼,如果它由於錯誤而停止,我添加一個begin..rescue語句。我敢肯定,一定有更好的方法。我剛剛運行腳本將數據導入某個文件的數據庫,並在一小時後停止(大量文件,不要求),因爲出現了一些我不知道會發生的錯誤。非常煩人,我敢肯定這不是寫更強大的代碼是我的錯。我怎麼做?

回答

2

我不確定始終可以在沒有首先體驗它們的情況下始終預測異常。既然您知道數據庫有時會失敗,您可能會爲未來添加更好的異常處理,但在這個意義上,經驗是唯一真正的老師。

但是,我認爲你可能會過於快速地編寫自己的錯誤處理程序。對於生產代碼,顯然有些情況下你希望能夠輕鬆捕捉並顯示一個好的錯誤信息(例如太多的數據庫連接),但有時候允許錯誤浮起來實際上是最強大的事情腳本可以做。如果我的rubygems設置有問題導致你的寶石吐出錯誤,我不希望你把它們藏在「出錯了!」之後。我寧願看到錯誤,以便我可以開始工作。

抓住真正重要的錯誤,並且可以做些事情,比如在放棄之前重試幾次HTTP連接。然而,除此之外,如果對錯誤沒有任何可以做的事情,那麼讓它浮出水面並不是什麼好事。

+0

讓它飄起來對我來說沒有意義,因爲我不是在寫圖書館。這個錯誤已經浮現在我的案例中,除非我嚴重誤解Ruby中異常處理的工作方式(很可能)。問題是,當我寧願讓它們繼續運行時,錯誤會停止腳本,我可以稍後檢查日誌文件中的錯誤或其他內容。 – ehsanul 2010-07-21 04:38:14

+3

@ehsanul - 只有在知道繼續跑步的情況下才能繼續跑步。吞嚥所有錯誤是一種非常危險的行爲,特別是如果異常表明如果您繼續進行會導致系統損壞的關鍵問題。但是,當你知道這個問題只是暫時的,而且可能只適用於一項孤立的任務時,情況就不同了......但這是非常具有情境性的,每個單獨的例外都必須單獨處理:/ – Matchu 2010-07-21 04:52:36