2010-08-28 110 views
0

建議在finally塊中擁有業務邏輯嗎? 工作結束後(無論是否成功),我必須發送電子郵件通知。我可以將電子郵件邏輯放在最終塊中嗎?我可以在Finally塊中擁有業務邏輯嗎?

+0

當然,但是當電子郵件失敗時會發生什麼? – leppie 2010-08-28 05:25:39

+0

@leppie這個案子也是我的想法。那麼你在哪裏建議放置電子郵件代碼? 在另一個筆記上,我已經讀過,finally塊總是應該用來清理資源。那麼保留一些業務邏輯真的是一個不好的習慣嗎? – Mayank 2010-08-28 05:32:25

回答

1

我能想到的主要危險是finally塊有能力默默吞下異常並從try塊本身返回值。

例如,

try { 
    doSomethingFancy(); 
} finally { 
    sendEmail(); 
} 

如果doSomethingFancy拋出一個異常,你會試圖發送電子郵件。如果以某種方式發送電子郵件失敗,sendEmail可能會拋出異常。這個例外將會「覆蓋」原來拋出的一個,你永遠不會看到它。它會消失。

你可以解決這個代碼防守更try/catch塊,但只是知道......

+0

我已經實現了(幾次)幫助類,它將運行一系列操作,並在特定操作失敗時捕獲異常/繼續。一旦所有動作都被執行,如果有任何異常被拋出,它們將被彙總爲一個主異常,我會拋出異常。 – 2010-08-28 06:01:02

0

你可以做的是,在案件catch塊,如果你打算髮送錯誤條件指定的電子郵件ID。 finally塊通常主要用於資源的優化釋放。我不建議在finally塊中發送電子郵件或執行任何業務規則。

1

理想情況下,您應該在Try塊中擁有業務邏輯,並且最後塊應包含任何清理任務或任何必須發生的事情,而不管try塊的成功或失敗。您還需要確保finally塊中的代碼不會導致任何異常,否則在Steven提到的情況下,原始異常將會丟失(如果有)。

0

在我的腦海裏,

try { 
    doSomethingFancy(); 
catch(Exception ex) { 
    logError(ex); 
} 
sendMail(); 

是爲這個完美的模式。最後,塊應該只用於清除try塊中的代碼可能留下的混亂。

+0

但是,正如Steven指出的那樣,如果sendMail拋出一個異常會發生什麼?它不會讓我的系統崩潰嗎? – Mayank 2010-08-28 17:25:22

+0

當然,但是你可以把它放在一個單獨的try catch塊中。只要有兩段代碼以不同的方式處理Exception,您當然需要將它們放在單獨的try catch塊中。 – VdesmedT 2010-08-28 21:46:57