2012-07-12 19 views
3

我有一個簡單的樣式問題。在我編寫的應用程序中,有幾個類方法,它們包括try/catch塊以及取決於塊結果的塊外部的函數。例如(在psudo代碼):編程風格:嘗試捕獲和外部依賴

try { 
    start_transaction; 
    persist_data; 
    stop_transaction; 
} 
catch { 
    rollback_transaction; 
} 
finally { 
} 

if (transaction_successful) 
    send_message; 

我能想到的測試,如果交易成功,將設置在try catch塊的方法可變標誌,然後在if語句測試它的唯一方法。當然這會起作用,但是我很想知道傳統的「智慧」是什麼?也許「send_message」應該在try catch塊中,儘管這可能是不必要的混亂?我想這是一個相當直接的問題 - 只是爲了確保我的代碼結構合理。

+3

好,如果你只是想在事務成功的時候發送消息,我會建議把它作爲try塊本身的一部分。你爲什麼認爲這會是一種「不必要的混亂」? – Sujay 2012-07-12 02:19:46

+0

我猜想當我閱讀代碼時,我喜歡在單個「塊」中看到單個函數 - 可能只是從我的Fortran時代開始的一段時間:)。更重要的是,如果send_message調用失敗,那麼事務將被回滾。這是一個問題,因爲交易是主要的(而且是關鍵的)功能(而不是交易成功的信息) – skyman 2012-07-12 02:28:21

+0

由於其他方面a)至少引入了一個額外的變量和b)額外的邏輯,看看你如何得出將發送消息放入try塊的結論會增加混亂。 – Voo 2012-07-12 02:37:28

回答

4

看來您需要更多地考慮適當的軟件層次/增加此類/方法的內聚力。 從所提供的示例看來,在這裏您有DAL /業務層混合(persistense +一些業務活動),這就是您需要在catch塊之後以相同方法對事務結果作出反應的主要原因。

通過適當的分層它可能看起來如下:

  • 持續失敗,則拋出檢查/運行時異常給調用層表示此情況(這是由你來決定如何指示失敗正好,depdends你的架構方法),
  • 調用類捕獲異常並執行錯誤處理 - 或相應發送消息嘗試「堅持」方法的調用之後塊右

當然,您可以設置標誌(如您所建議的),並使用AOP建議來處理這種情況(尤其是,如果'send_message'是輔助功能)。

+0

這是一個很好的觀點。代碼的結構可能會更好。本質上,消息處理正在進行:接收消息,保存一些消息數據,然後通知其他感興趣的系統新數據已到達。如果通知失敗,那麼數據應該仍然存在。 – skyman 2012-07-12 02:43:25

+0

在這種情況下,其他海報的答案在這裏完全適用 - 您可以在try塊中移動send_message。它也看起來像同步/異步事件發佈/分發設計方法使用的經典候選。所以你可以在這裏發起一個事件(表明消息已被處理/接受),並將通知任務留給這個事件的處理者/訂閱者。取決於你使用的技術,但通常他們都有類似的東西。 – 71taa 2012-07-12 02:57:39

1

它會很簡單,可以放在try區塊中。 「雜亂的代碼」是個人喜好的問題,但這使事情變得簡單。

1

假設(,雖然這看起來很明顯從你的代碼),你試圖發送一條消息,當且僅當事務成功時,我認爲將它作爲try塊的一部分是有意義的本身。

在我看來,它不會是一個「不必要的混亂」,因爲消息需要發送成功。如果消息有部分即使交易失敗發送,那麼它會一直顯然是有道理的,保持一個標記和跟蹤交易狀態(並相應地修改您的消息

1

把它放在try塊內,但是如果在執行send_message時拋出異常,最好有自己的catch塊 - 這是通過指定適當的異常類來完成的。