2010-04-17 75 views
4

看來我在我的代碼中隨處可見begin ... rescue ... end聲明!這似乎不是正確的做法。在Ruby中替代救援?

任何人都可以建議如何我可以捕捉任何異常,而無需將所有內容放入begin ... rescue ... end?任何方式只是告訴Ruby閉嘴,即使引發異常也繼續前進?

+0

如果引發異常,通常是因爲發生了Ruby *無法自動繼續的情況。如果你可以設計一個適合你的問題的代碼片段,那麼這就是拯救部分 – Gareth 2010-04-17 05:32:06

+0

的一個重點,它可以讓我們判斷你是否有異常需求。 – 2010-04-17 05:46:02

回答

10

與其他語言一樣,對於任何非平凡的程序,實際上您都需要經過深思熟慮的架構來處理異常。一種方法是在您的項目中定義異常處理範圍,然後通常希望在範圍邊界處捕獲(挽救)異常。有一個權衡。越接近堆棧,發生異常的位置越多,關於觸發它的條件的上下文信息也越多。如果你試圖過於細化,你會遇到你所描述的問題。另一方面,如果你只在棧頂捕獲異常(在「main」中),那麼就沒有上下文。因此,定義異常處理範圍涉及評估與您的特定程序或系統有關的權衡。

Ruby使我們能夠「重試」 - 在某些其他語言中不可用。這應該謹慎使用!但是在有意義的地方(例如等待網絡或資源被釋放),這些異常需要在本地處理。

否則,我傾向於在大型項目中對相當粗粒度級別的異常作用域進行定義。捕獲一些上下文信息通常是有用的,因爲從起始點到各種異常範圍邊界異常冒泡。爲了解決這個問題,您可以通過定義一些您自己的特定於應用程序的異常類型來擴展Ruby異常類層次結構,但同樣存在權衡。您的項目應具有關於何時使用自定義異常類型與捕獲消息字段中的上下文數據,消息字段應該包含什麼類型的信息等的明確標準,以及用於對代碼可生成的消息進行編目的策略。

在大多數情況下,可以允許異常向上傳播到中央處理程序,記錄(針對技術團隊和支持),爲用戶生成有用的錯誤消息,並確定條件是否足夠嚴重要求您的程序退出。通常,所有的異常都應該在您的代碼中或在您使用的應用程序框架內處理。不應該允許任何異常轉移到語言運行時或操作系統的缺省異常處理。

這些是我的想法,主要基於其他語言的經驗,但我認爲他們適用於相當普遍。總之,在一個大型項目中,您需要付出相當大的努力來設計異常處理,而不是專門的方法。

4

有一兩件事可以使它看上去有點吸塵器把救援在方法的結束,所以你並不需要一個開始和縮進的另一個層面:

def get_file_prompt 
    print "Enter file name: " 
    return File.open(read) 
rescue StandardError 
    puts "File could not be opened" 
    return nil 
end 
1

哦,不。例外的要點是它們是必須處理的條件。

想想這樣:例外是你的朋友!沒有他們,你將不得不寫很多無聊的條件陳述,這些陳述很難閱讀和維護。

如果您正在學習Ruby(或任何帶有異常系統的語言),處理異常是最重要的方面之一,您應該花時間弄清楚如何處理它們,何時重新處理 - 提醒他們,以及何時可以忽略他們。

6
def action 
    yield 
    rescue 
     .... 
    ensure 
     .... 
end 

action { stuff_goes_here }